|
Is it just me or has the standard of questions in this forum hit an all-time low?
How do I write a program?
What steps should I take to blow my nose?
Is breathing essential?
Pls heeeeeeeeeellllllllllppp meeeeeeee!!!
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
Phil J Pearson wrote:
Is it just me or has the standard of questions in this forum hit an all-time low?
It's just all too easy to throw your question/problem over the fence to see if an answer comes back over. Problem-solving skills seem to be scarce. I see too much of the "As long as it works, I don't need to know how, and if it stops working, I can ask around." mentality.
"Opinions are neither right nor wrong. I cannot change your opinion of me. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
DavidCrow wrote:
"As long as it works, I don't need to know how, and if it stops working, I can ask around." mentality.
Another reason why everyone should study geometry and assembly language, regardless of their field of study.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Sorry if this seems complex (it is!). Please bear with me.
I have an application that calls into a dll. The app is dynamically linked to MFC; the dll is statically linked. Both are MFC71. Rough outline of problem is:
1. App creates a CWnd
2. App calls into dll
3. Dll creates a CWnd (uses AFX_MANAGE_STATE everywhere necessary)
4. App destroys window created in step 1 (it was a splash dialog)
here comes the weirdness...
5. Dll's AfxWndProcDllStatic processes WM_NCDESTROY and ends up calling MFC's OnNcDestroy for the window created in step 3.
6. OnNcDestroy calls PostNcDestroy which does delete this; for the CWnd from step 3. 
7. Everything else carries on sweetly until the dll tries to reference data in the CWnd that was vandalised.
Please can someone explain what the ? is happening to cause step 5? 
Incidentally, all this happens on the same (main) thread, although other threads do get created elsewhere.
Thanks in advance,
Phil
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
They are not sharing the same temporary window mapping tables.
Also, the 'main window' of your application is probably being set to the splash window (the first one created).
You might try changing the m_pMainWnd of the CWinApp to your second dialog, once it appears on the screen (perhaps in OnInitDialog), and see if that helps any, then when your splash window is zapped, the program won't think you just killed the 'primary' window of the application.
If that does not work, you might have to create a hidden window to act as the 'top level window' of your program, and use it as the parent for your splash window AND the other dialog. If you choose this route, then pass the HWND, not the CWnd, as the parent to the dialog in the DLL, since you statically linked to MFC within the DLL.
|
|
|
|
|
Thanks for the ideas ... but ...
The main window of the app is set explicitly by code in InitInstance when the main frame is created.
The dll window is always hidden (it's just there to host an invisible ActiveX control). It's parent is NULL.
The root of the problem is that when CWnd::DestroyWindow() (for the splash dialog) calls ::DestroyWindow(hWnd) (with the splash dialog's hWnd) Windows emits a WM_NCDESTROY with a completely different hWnd (that of the dll's window).
Just thought ... maybe it's something to do with the fact that both windows have NULL parent ... ? I'll investigate now.
Phrustrated Phil
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
Making the hidden dll window a child of the DesktopWindow instead of a child of NULL fixed the problem. Don't ask me why! I must have missed the bit of the documentation that says
"NULL is the default value for the parent window but if you're too idle to find the window a proper, caring parent then you have to be prepared for Windows destroying the window when it feels like it."
Thanks to Blake Miller for putting me on the track.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
Hi ,
I had made an application which can send mails .
I had done this by loading MAPI32.dll.
Now my doubt is "Is there any method to display mails to my application which is coming to my outlook account ?"
Thanx in advance
Rgds
Sunil
|
|
|
|
|
If you receive you mail from server using Outlook, you can find received messages in
C:\Documents and Settings\{User name}\Local Settings\Application Data\Identities\id\Microsoft\Outlook Express (this folder may be changed in Outlook settings)
If you planing to interact whith mail server from you program (not using Outlook), you mast implement needed mail protocol (like POP3,...) self  (see C++/Internet section on this site)
|
|
|
|
|
Hi,
you must have to look 4 articles related 2 outlook automation. Have a look @ the following article
http://www.codeproject.com/com/outlookaddin.asp
This may help you
Sujan
|
|
|
|
|
|
If the dll is not loaded into memory then it's not being used. However, you probably mean "how many programs might potentially need the dll if and when they are run". The answer is there's not really any way to tell. You could run the depends tool on all the executables on the computer but you still wouldn't know because the dll might be loaded at run-time by something.
Shared dll's are supposed to be registered so they appear in the registry but there's nothing to guarantee that.
The only way to be sure is to delete the dll and then run absolutely every application using every possible feature under every possible condition. If something complains then the dll was needed. If not then it (probably) wasn't.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
You could use the windows search for files option to find *.exe and *.dll files that contain the name of the dll in question
--
Help me! I'm turning into a grapefruit!
Phoenix Paint - back from DPaint's ashes!
|
|
|
|
|
benjymous wrote:
You could use the windows search for files option to find *.exe and *.dll files that contain the name of the dll in question
This is no better than using the depends tool. It does not take account of the possibility of programs loading dll's at runtime. The name of the dll may be built at runtime from user input or registry/ini settings for example.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
Can u tell a method to convert unsigned short* to CString ??
Thanx in advance.
Rgds
Sunil
|
|
|
|
|
That depend on what data type pointed by unsigned short*, etc. string, wide char string number ..., and what string representation you want.
|
|
|
|
|
|
You asking "how convert pointer to string", or "how convert data ref by pointer to string" ?
And if data, you mast say what kind of data (unsigned short * pointer may point to Unicode string, WORD value, 16bpp raster data ....)
|
|
|
|
|
It is pointer to a Ascci string.
I have to display it in a message box.
So I have to convert it to CString.
|
|
|
|
|
simple (if there ASCII coded string  )
CString((char *)data)
|
|
|
|
|
I got only the first letter???
|
|
|
|
|
That meens, that you have not ASCII data stored by pointer.
You mast know, what coding used (Unicode, MBS, BSTR, wide char), and corectly convert pointer to CString constructor.
|
|
|
|
|
Sorry I mistook .
It is pointed to BSTR.
|
|
|
|
|
|
It works!!!!!!!
Thanx a lot..
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
