|
|
And Im thankful twice. 
|
|
|
|
|
here's the situation:
we have an application which uses an embedded instance of IWebBrowser2, and this browser is intended to be used on a site which requires a secure login. so, the user will bring up the browser window embedded in our app, login, and do his work. this works fine until the site in question has a pop-up window - when that happens, the embedded browser launches a new instance of IE for the popup, which means the popup doesn't get any of the security information / cookies from the main browser window, and it will force the user to re-login. we want to prevent that.
a poster here[^], suggests that the way to deal with this is to handle the NewWindow2 notification, create a new embedded browser in the handler, associate that with the main browser and let the new browser take care of the popup. i guess that sounds logical, but i'm not sure what that means in terms of new threads and new objects (and who cleans them up). the documentation is pretty weak, as usual.
so, has anyone else ever done anything like this ?
|
|
|
|
|
Chris Losinger wrote: so, has anyone else ever done anything like this ?
No have you. The KB seems straight forward. Let us know if it works will you?
led mike
|
|
|
|
|
thanks for all your help. much appreciated.
|
|
|
|
|
Dude, I was serious. I would really like to know if that actually works in your situation.
led mike
|
|
|
|
|
hmmm. ok.
i'm still not sure of how to make it happen. but i'll let you know.
|
|
|
|
|
conclusion:
yes, it works fine. when the parent browser says it wants a new window, i create a new window (CWindowImpl, this is ATL), stuff a WebBrowser2 control in there and give the parent the IDispatch ptr to the new browser. no threads needed.
also need to handle window sizing and naming, but those are simple.
modified on Friday, June 6, 2008 11:57 AM
|
|
|
|
|
Wow that's pretty cool. And something that is relatively easy to implement using a browser so that's somewhat unique. Thanks for taking the time to post back!
led mike
|
|
|
|
|
Hi,
My application is setting the character set to DEFAULT_CHARSET , but using lfFaceName as "Tahoma" . Now when I type anything onto a dialog.. the text is turning to BOLD. Can I know whether this is proper.
Thanks,
Venkat
|
|
|
|
|
Your problem is Japanese character or font style?
|
|
|
|
|
I'd like to add visual xp style to my vc6 project, so I add a manifest file. It looks fine. But when the program exits, a exception will appear that shows "Access Violation". If I remove the manifest file, the program will normally exit.
Who can help me? Thanks!
modified on Monday, June 2, 2008 10:39 PM
|
|
|
|
|
Have you discovered anything with the debugger?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Without seeing code its difficult for anyone to answer. As suggested already, you should use call stack to trace down the problem.
|
|
|
|
|
I have debugged but find nothing. The exception occurs at the function:
BOOL CObject::IsKindOf(const CRuntimeClass* pClass) const
{
ASSERT(this != NULL);
// it better be in valid memory, at least for CObject size
ASSERT(AfxIsValidAddress(this, sizeof(CObject)));
// simple SI case
CRuntimeClass* pClassThis = GetRuntimeClass();
return pClassThis->IsDerivedFrom(pClass);
}
Error message is "0xC0000005: Access Violation".
Another question: I have create a CAnimateCtrl in a CWnd. Normally, the backgound of the CAnimateCtrl is black. but when adding the manifest file the backgound is white!!
|
|
|
|
|
Here is my call stack:
CObject::IsKindOf(const CRuntimeClass * 0x5f4afeb0 struct CRuntimeClass const CView::classCView) line 48 + 8 bytes
CFrameWnd::GetActiveView() line 1168 + 31 bytes
CFrameWnd::OnCmdMsg(unsigned int 59396, int 5176507, void * 0x0012e710, AFX_CMDHANDLERINFO * 0x00000000) line 893 + 8 bytes
CWnd::OnNotify(unsigned int 59396, long 1239928, long * 0x0012e8c4) line 2125
CMainFrame::OnNotify(unsigned int 59396, long 1239928, long * 0x0012e8c4) line 3110
CWnd::OnWndMsg(unsigned int 78, unsigned int 59396, long 1239928, long * 0x0012e908) line 1620 + 40 bytes
CWnd::WindowProc(unsigned int 78, unsigned int 59396, long 1239928) line 1596 + 30 bytes
AfxCallWndProc(CWnd * 0x01c8c2b8 {CMainFrame hWnd=???}, HWND__ * 0x00280442, unsigned int 78, unsigned int 59396, long 1239928) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00280442, unsigned int 78, unsigned int 59396, long 1239928) line 379
AfxWndProcBase(HWND__ * 0x00280442, unsigned int 78, unsigned int 59396, long 1239928) line 220 + 21 bytes
USER32! 77d18734()
USER32! 77d18816()
USER32! 77d1b89b()
USER32! 77d1b903()
COMCTL32! 7719ab19()
COMCTL32! 77201fc9()
COMCTL32! 77204f8c()
COMCTL32! 772053cb()
COMCTL32! 772068ba()
USER32! 77d18734()
USER32! 77d18816()
USER32! 77d1c63f()
USER32! 77d1f65d()
CWnd::DefWindowProcA(unsigned int 130, unsigned int 0, long 0) line 1011 + 32 bytes
CWnd::Default() line 258
CWnd::OnNcDestroy() line 843
CWnd::OnWndMsg(unsigned int 130, unsigned int 0, long 0, long * 0x0012ef00) line 1836
CWnd::WindowProc(unsigned int 130, unsigned int 0, long 0) line 1596 + 30 bytes
CControlBar::WindowProc(unsigned int 130, unsigned int 0, long 0) line 480 + 20 bytes
CReBar::WindowProc(unsigned int 130, unsigned int 0, long 0) line 322
AfxCallWndProc(CWnd * 0x01c8cad4 {CReBar hWnd=0x00140fde}, HWND__ * 0x00140fde, unsigned int 130, unsigned int 0, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00140fde, unsigned int 130, unsigned int 0, long 0) line 379
AfxWndProcBase(HWND__ * 0x00140fde, unsigned int 130, unsigned int 0, long 0) line 220 + 21 bytes
USER32! 77d18734()
USER32! 77d1d05b()
USER32! 77d1b4c0()
USER32! 77d1dabd()
NTDLL! 7c92eae3()
CDocument::OnCloseDocument() line 801
COleDocument::OnCloseDocument() line 663
CDocTemplate::CloseAllDocuments(int 0) line 357
CDocManager::CloseAllDocuments(int 0) line 569
CWinApp::CloseAllDocuments(int 0) line 99
CFrameWnd::OnClose() line 805
CWnd::OnWndMsg(unsigned int 16, unsigned int 0, long 0, long * 0x0012f348) line 1836
CWnd::WindowProc(unsigned int 16, unsigned int 0, long 0) line 1596 + 30 bytes
AfxCallWndProc(CWnd * 0x01c8c2b8 {CMainFrame hWnd=???}, HWND__ * 0x00280442, unsigned int 16, unsigned int 0, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00280442, unsigned int 16, unsigned int 0, long 0) line 379
AfxWndProcBase(HWND__ * 0x00280442, unsigned int 16, unsigned int 0, long 0) line 220 + 21 bytes
USER32! 77d18734()
USER32! 77d18816()
USER32! 77d1b4c0()
USER32! 77d1b50c()
NTDLL! 7c92eae3()
USER32! 77d1d598()
UXTHEME! 5adc3c20()
UXTHEME! 5adde300()
UXTHEME! 5adc1ac7()
UXTHEME! 5adc367a()
USER32! 77d2f11d()
USER32! 77d18734()
USER32! 77d18816()
USER32! 77d1c63f()
USER32! 77d1f65d()
CWnd::DefWindowProcA(unsigned int 274, unsigned int 61536, long 132342) line 1011 + 32 bytes
CWnd::Default() line 258
CWnd::OnSysCommand(unsigned int 61536, unsigned int 61536) line 418 + 15 bytes
CFrameWnd::OnSysCommand(unsigned int 61536, long 132342) line 1046
CWnd::OnWndMsg(unsigned int 274, unsigned int 61536, long 132342, long * 0x0012f908) line 1860
CWnd::WindowProc(unsigned int 274, unsigned int 61536, long 132342) line 1596 + 30 bytes
AfxCallWndProc(CWnd * 0x01c8c2b8 {CMainFrame hWnd=???}, HWND__ * 0x00280442, unsigned int 274, unsigned int 61536, long 132342) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00280442, unsigned int 274, unsigned int 61536, long 132342) line 379
AfxWndProcBase(HWND__ * 0x00280442, unsigned int 274, unsigned int 61536, long 132342) line 220 + 21 bytes
USER32! 77d18734()
USER32! 77d18816()
USER32! 77d1b89b()
USER32! 77d1b903()
UXTHEME! 5ade881f()
UXTHEME! 5adc1ac7()
UXTHEME! 5adc367a()
USER32! 77d2f11d()
USER32! 77d18734()
USER32! 77d18816()
USER32! 77d1c63f()
USER32! 77d1f65d()
CWnd::DefWindowProcA(unsigned int 161, unsigned int 20, long 132342) line 1011 + 32 bytes
CWnd::WindowProc(unsigned int 161, unsigned int 20, long 132342) line 1597 + 26 bytes
AfxCallWndProc(CWnd * 0x01c8c2b8 {CMainFrame hWnd=???}, HWND__ * 0x00280442, unsigned int 161, unsigned int 20, long 132342) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x00280442, unsigned int 161, unsigned int 20, long 132342) line 379
AfxWndProcBase(HWND__ * 0x00280442, unsigned int 161, unsigned int 20, long 132342) line 220 + 21 bytes
USER32! 77d18734()
USER32! 77d18816()
USER32! 77d189cd()
USER32! 77d196c7()
CWinThread::PumpMessage() line 853
CWinThread::Run() line 487 + 11 bytes
CWinApp::Run() line 400
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00151f17, int 1) line 49 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00151f17, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 7c816fd7()
|
|
|
|
|
I have used objective grid in my project. I noticed when double click the cell and input will cause a debug error as follows:
memory check error at 0x01CE4DE3 = 0xBA, should be 0xFD.
memory check error at 0x01CE4DE4 = 0x0D, should be 0xFD.
memory check error at 0x01CE4DE5 = 0xF0, should be 0xFD.
memory check error at 0x01CE4DE6 = 0xAD, should be 0xFD.
Warning: You did start a redraw while the grid was redrawing its contents. You might consider delay this drawing by passing GX_INVALIDATE as parameter if possible or if you only call InvalidateRect() and do not UpdateWindow()
memory check error at 0x0488E583 = 0xBA, should be 0xFD.
memory check error at 0x0488E584 = 0x0D, should be 0xFD.
memory check error at 0x0488E585 = 0xF0, should be 0xFD.
memory check error at 0x0488E586 = 0xAD, should be 0xFD.
It should be related to manifest file. I don't know the former exit exception is also caused by objective grid and manifest file.
Looking forward to your help!
|
|
|
|
|
this is what i'm doing:
m_pD3D = Direct3DCreate9( D3D_SDK_VERSION ) ...
D3DPRESENT_PARAMETERS d3dpp;
ZeroMemory( &d3dpp, sizeof(d3dpp) );
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = D3DFMT_UNKNOWN;
m_pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING,
&d3dpp, &m_pd3dDevice )
...
D3DXCreateTextureFromFileEx(m_pd3dDevice, pSrcFile.c_str()
,D3DX_DEFAULT,
D3DX_DEFAULT ,
D3DX_DEFAULT,
D3DUSAGE_RENDERTARGET,
D3DFMT_A8R8G8B8,
D3DPOOL_DEFAULT,
D3DX_FILTER_NONE,D3DX_DEFAULT,0,NULL,NULL,
&(pStatData->m_Texture)))
after about 300 hundred textures from files it this returns D3DERR_OUTOFVIDEOMEMORY.
sizes are: I check the height (which is rounded to power of 2) of the returned texture at surface level 0.
first 100 textures of varying sizes, often small, 32 or 64 height on avergae.
then 200 textures all with 256 height.
I make sure to release() unused textures and directX resources and not making memory leaks in general.
The answer can be:
1. I should set some flag to make this all work.
2. I should load big textures with multiple images in them.
3. I'm passing some hard limit and I must cut down in the size of image resources.
|
|
|
|
|
Your description suggests an unidentified memory leak. Look for something that's not being freed. Maybe delete needs to be called for one of these objects.
If you can't find it, you can try the Signal Flare debugging pattern: Here, for one statement that allocates something, temporarily replace it with a loop that allocates 50 of them. Free the 50 where you were originally freeing the single object.
Then run your program and count how many textures it takes to run out of memory. If it's 300, that statement isn't the memory leak, so go on to the next one. If it runs out of memory after 6 textures (300 / 50), you've found the leak.
|
|
|
|
|
|
It seems you are trying to acquire the video memory more than that actually available, even though you are making sure to release the unused textures, still the required texture may requires more memory. you need to have an algorithmn to make sure reasonable number of textures which is most used by tracking the available video memory and remaining texture to be loaded to video memory whenever needed by releasing the least used one.
That you need efficient direct3d resource management alogorithmn.
see [Automatic Texture Management ^]
say if you load all the textures at once 50 * 32 * 32 * 4 + 50 * 64 * 64 * 4 + 200 * 256 * 256 * 4 = 50 MB, while reasonable video memory of GPU is 64 MB, 50 MB is huge size only for textures.
BTW, do you need this D3DUSAGE_RENDERTARGET flag, it is used if you want to render to texture.
|
|
|
|
|
Thank you.
I made an experiment with calling D3DXCreateTextureFromFileEx() on 10 PNG images of size 8192X8192 and received no error code.
Rajkumar R wrote: say if you load all the textures at once 50 * 32 * 32 * 4 + 50 * 64 * 64 * 4 + 200 * 256 * 256 * 4 = 50 MB, while reasonable video memory of GPU is 64 MB, 50 MB is huge size only for textures.
This should be about 260 MB so it doesn't seem like actual GPU mem is a concrete limit on the texture memmory size.
Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (m_pSprite->Draw()) which is the only thing I do with the textures.
Another thing is trying to load 290 of those giant textures (maybe 300 is some strange number of resources limit).
Rajkumar R wrote: BTW, do you need this D3DUSAGE_RENDERTARGET flag, it is used if you want to render to texture.
I changed to D3DUSAGE_DYNAMIC. Loading textures still stopped at the same image in the series (actually exactly 1 image less), BUT, some error relating to ID3DXFont
(using <code>ID3DXFont::DrawText() suddenly draw some wacky straight scribbles that resemble the actual text) that I had and had a reason to believe happened because of my "texture loading abuse" was fixed.
|
|
|
|
|
Hanan888 wrote: Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (m_pSprite->Draw()) which is the only thing I do with the textures.
Some interesting stuff: the 8192X8192 is probably scaled down to 2048X2048.
This I suspect from checking the surface level 0 description.
Also, from easy to see differences when drawing a portion of the texture.
When changed the size of image to 2048X2048, the part drawn looked similar to the original file.
|
|
|
|
|
Hanan888 wrote:
Perhaps there are more things that worth checking for example if this creates any problem (error or performance) when drawing (m_pSprite->Draw()) which is the only thing I do with the textures.
Hope this is of any interest to you 
* I've g_pSprite->Draw() on a 225X225 portion of the 2048X2048 texture, 10,000 times during my render().
First render() took 4-5 milisec, next ones 1-2 milisec. no error ever happened.
* but I noticed my system start to sweat after 100 draw() for render().
which is great.
* when offseting outside of original & surface level 0 source rectangle ( I mean wehre they are equal as in the 2048X2048 case)
(ID3DXSprite::Draw(pTexture,RECT(4000,4225,4000,4225),..))
no error returned and some unrelated yet consistent pattern is shown (which was some khaki color).
when doing this using the 8192X8192 some other unrelated pattern shown (that one was a little darker).
And bottom line I must know the size that will show my images 'as is'.
|
|
|
|
|
you just use the DirectX cap viewer to check the maximum texture size, MaxTextureWidth, MaxTextureHeight of [D3DCAPS9 Structure^], it should be some thing like 2048 X 2048, so the texture creation more than this dimension is ignored i think, so the total size is 10 * 2048 * 2048 *4 = 40 MB, not 260 MB (8192X8192). you just try a texture size of 1024x1024* 50 PNG = 200 MB.
You cannot create texture more than the max texture size in D3DCAPS9.
Hanan888 wrote: I've g_pSprite->Draw()
PS: use ID3DXSprite::Begin and end also otherwise every call to Draw() internally calls begin and end.
Hanan888 wrote: * but I noticed my system start to sweat after 100 draw() for render().
Do you mean CPU temperature and CPU usage goes high, if so you are rendering in a tight loop, reduce the framerate to the reasonable framerate.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
