Re: Heavy Tooltip-Problems in mixture of MFC Regular and Extension DLL

From:

Scot T Brennecke <ScotB@Spamhater.MVPs.org>

Newsgroups:

microsoft.public.vc.mfc

Date:

Sat, 06 Jun 2009 02:27:28 -0500

Message-ID:

<4A2A1A60.6090004@Spamhater.MVPs.org>

As Ajay and others have said, your problem is the mixture of static MFC
and DLL MFC. It is not an option. You are getting incorrect results
because of the AFX_MODULE_STATEs not being correctly set for the code in
the thread context. The module states provide the handle to the
resource module to find your resources. They also connect you with the
proper CWinApp object so that the window handle maps can be correctly
located and so that messages will be routed in the correct module state
context.

You speak of unchangeable restrictions, but whoever puts those
unreasonable restrictions on you has broken your code. Not mixing
static and DLL MFC is a restriction you also have to follow.

MueMeister wrote:

It's difficult to say cause debug information seem to be strange but
the assertion itsself is triggered in CWnd::DestroyWindow:

"ASSERT(m_hWnd == hWndOrig);"

It seems that a CToolTipCtrl is to be destroyed but already dead. But
this is only an assumption. If I ignore the assertion I can repeat
jumping between the dialogs two or three times but then the applications
fails.

T.I.A.
MueMeister

David Ching schrieb:

What exactly is the assert condition that is failing? Does proper
operation still occur?

-- David

"MueMeister" <mue@gmx.de> wrote in message
news:%23lAspeH5JHA.1372@TK2MSFTNGP05.phx.gbl...

Ajay schrieb:

On Jun 3, 10:49 am, MueMeister <m...@gmx.de> wrote:

Hi Ajay,

Mhmmm, this is because of restrictions I cannot change. But explain
why this should be dangerous since no MFC types are exchanged between
the application and the regular MFC DLLs ?

First of all, you are wasting memory for no reason. Restrictions cant
justify this.

No disagreement :-)

Are you saying you have made sure that a method calling from app to a
DLL doesnt need any of the MFC objects(like main window, state etc) in
the DLL? If so, what exactly is the purpose of using MFC in those
DLLs? You are going to run into all sorts of problems when any method
in the DLL wants to use any MFC object(directly or indirectly
(callback). You will get subtle bugs, very hard to trace.

The DLLs 'B' and 'C' expose classes which are derived from types
exposed by the extension DLL 'A' (Especially dialogs are created).
So, I thought if e.g. CString is used in the regular DLLs 'B' and 'C'
I need MFC in those DLLs, too ?! Maybe I have a misunderstanding here!

Also to calrify, you can mix Regular and Extension DLLs without any
problem.

OK.

--
Ajay

Thank you very much for your help
MueMeister