Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Modeless Dialog from DLL causes Assertion fails

Status
Not open for further replies.

Aleksei

Technical User
Mar 4, 2002
10
0
0
NL
Hi,

I am working on a DLL which will display a modeless dialog
box. The executing program first calls an initialisation
routine in the DLL (which calls .Create()), and then starts
polling another routine, which should update a certain
control in the Dialog. The polling routine does this by
calling a member function of dialog box, which updates
the associated member variable and then calls its inherited
UpdateData(true).

When debugging the application, I get an Assertion error at
when calling the UpdateData function. Further tracing the
problem I found the fail in WinCore.cpp (CWnd::AssertValid).
The call that causes the fail is afxMapHWND, which returns
a NULL value. The comment for this ASSERT check says:
Code:
//should also be in the permanent or temporary handle map
A comment a little lower says :
Code:
// Note: if either of the above asserts fire and you are
// writing a multithreaded application, it is likely that
// you have passed a C++ object from one thread to another
// and have used that object in a way that was not intended.
// (only simple inline wrapper functions should be used)
//
// In general, CWnd objects should be passed by HWND from
// one thread to another.  The receiving thread can wrap
// the HWND with a CWnd object by using CWnd::FromHandle.
//
// It is dangerous to pass C++ objects from one thread to
// another, unless the objects are designed to be used in
// such a manner.
What I basically have is the following:
Code:
CMyDialog myDialog;

DLLEXPORT int MyInitRoutine ()
{ 
  // MyInitRoutine actually get called twice. 
  if (myDialog.m_hWnd == NULL) 
    myDialog.Show(IDD_MYDLG, NULL);

  myDialog.UpdateFunction (); // <- works
}

DLLEXPORT int MyPollingRoutine ()
{
  myDialog.UpdateFunction(); // <- fails in UpdateData
}

CMyDialog::UpdateFunction ()
{
  // Update some member variables

  // Call UpdateData to allow DDX and DDV to apply the changes
  UpdateData (true);
}

If this is caused by the calling program being multithreaded
than how must I use this CWnd::FromHandle in the polling
routine ?

Or is there something else I am doing wrong ?

Regards,
Alex van L.
 
I noticed the DLLEXPORT in several of your routines. If you are relying on a method in a DLL to be automatically called in response to a notification message, this will not work because DLLs do not have messaging loops so there is no way for a DLL to receive a notification message. Be sure that the communication between your application and your DLL is working properly.

Hope this helps. Happy coding. :) *~-> EOR Candy <-~*
 
My suspicion is that you need to copy the header files for your .dll exported classes and function into your client application again and recompile the client.

It sounds to me like you've changed something in the .dll and the client program needs to be recompiled with the new header files.
 
OER Candy, AGF,
I am unclear with what you mean by Notification Message.
Are you talking about Windows Messages ? Unfortunatelly,
I have no control over the source code of the 'client'
application - I consider it as a black box, which calls
the Init routine twice (don't ask me why exactly), and
then continuously calls the Polling routine, which returns
the status. (The actual application area is an Automated
Test System for IC's, with a Handler or Prober attached
to automatically place IC's in the test socket (or position
a wafer underneath a probing-card). The software on the
test-system is fixed, but allows for any type of
Handler/Prober equiptment, through the use of a DLL (thru
the predefined 'API' as roughly described).

What I want to do, is to write such a DLL, which shows the
status of the H/P in a window, and allows some control over
it.

What I know is that the 'API' is implemented 'correctly'.
While debugging, I can see the calls to the routines take
place at the time when I expect it. But what fails are the
updates to the status window. For some reason, the handle
to the Window (myWindow) is not valid when called from
a different function than the one that Create'd the window
before. Other code in the Polling routine is executed
just fine!
But why not the UpdateData ??

Alex
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top