MFC DLL - ExitInstance hang on WaitForSingleObject

VC

    Next

  • 1. OnMouseDown not releasing
    Hello, I have an app I am developing and I need to get an even from the mouse when the user clicks a WMP (windows media player) activeX object. Well, I can capture the click, but the app thinks my left mouse button is still held down, then locks up, then only unlocks if I put the focus to another window and back to my app. Am I not releasing the mouse event properly? Here is my event: void CBrowse::OnMouseDownWmediaplayer(short nButton, short nShiftState, long fX, long fY) { if((fX >= -5 && fX <= 17) && (fY <= -518 && fY >= -541) ) { // find selected file and reload audio mySampleMethod(); ..... } } I notice that in normal dialog events, the onMouseDown will have a final line like the following: CDialog::OnLButtonDown(nState , point); I tried putting that in this function, but it makes no difference in the behavior. Any ideas what I am doing wrong? Thank you all for reading this, Rob K
  • 2. Problem to load .fnt fonts
    Hi, I am developing a WYSIWIG editor using .fnt fonts that I created in order to meet our product requirements. I am working on XP. Instead of putting the .fnt fonts in the windir\fonts directory, I used the AddFontResource method to load them when the application starts. On XP and W2000, I have not problem and the RichEdit control that I am using recognizes the font. On W95/98/Me the AddFontResource doesn't work and the application failed. I tried to put directly the .fnt fonts in the windir\fonts but it failed. It seems that it only accepts .fon fonts. Even if I load this type of fonts, AddFontResource fails. Questions: Can I use .fnt fonts on W95/98/Me? Can I load them using AddFontResource? Do I have to convert them to .fon fonts? If yes, could someone give me the format of this file (.fon) Do I have to implement the Microsoft Layer Unicode stuff? Thanks for your help and support -- Thanks. Philippe
  • 3. Help Needed with Stored Procedures
    Hi I'm using ODBC and VC++. My stored procedure has parameters like @pstr VarChar(100), @pVal1 numeric(9), @pVal2 numeric(9) and it returns a recordset. In my code CString strSP; strSP.Format("{call MySp('%s','%d','%d')}", str1, (long)Val1, (long)Val2); CMyRecorSet rs(m_db); try { rs.Open(CRecordset::snapshot,strSP); } catch(CDBException * pDB) { } I'm getting exception. Cannot convert datatype varchar to numeric. Why is this happening? Where is the exception occuring? Do i need to call SQLBindParameters? If yes, how to call it. Any sample code? Kindly help. Thanks in advance. Sanju
  • 4. GDI+ : property & methods list does not appear.
    hi, Priyanka again. i installed GDI+ on my system. but i never get the property & methods list after pressing the . or ->. i tried deleting the .ncb file also, but it didnt work. does anybody have idea about this? Thanks and regards, Priyanka

MFC DLL - ExitInstance hang on WaitForSingleObject

Postby RXJha2lz » Sun, 03 May 2009 08:31:01 GMT

i,

Here is a simple pooling class implemented into a MFC DLL project.

------------------------------------------------------------------------
BOOL CPooler::StartPooling()
{
// Create startup event
m_hStartupEvent = CreateEvent(NULL, TRUE, FALSE, NULL);

// Create main thread
m_hMainThread = CreateThread( NULL, 0, MainThreadProc,
static_cast<LPVOID>( this ), 0, &g_dwThreadID);

// Check for startup event
switch( WaitForSingleObject( m_hStartupEvent, 1000) )
{
case WAIT_TIMEOUT :
bRet = FALSE; // Thread time-out
break;

case WAIT_OBJECT_0 :
bRet = TRUE; // Thread sucessfully started
break;
}

// Close startup handle
CloseHandle(m_hStartupEvent);
m_hStartupEvent = NULL;

return bRet;
}

BOOL CPooler::StopPooling()
{
// Singal to main thread to stop
SetEvent(m_hEventKill);

// Check thread state
if (WaitForSingleObject( m_hMainThread, 10000) == WAIT_TIMEOUT)
{
// If thread is still running then stop it brutally
if (m_hMainThread != NULL)
{
TerminateThread( m_hMainThread, 0 );
}
}

// Thread is null
CloseHandle( m_hMainThread );
m_hMainThread = NULL;

return TRUE;
}


DWORD WINAPI CPooler::MainThreadProc(LPVOID lpParameter)
{
// Get pointer on CModBusTcpPooler class object
CPooler *pThis = reinterpret_cast< CPooler *>( lpParameter ) ;

// Cretae kill event (for main thread)
pThis->m_hEventKill = CreateEvent(NULL, FALSE, FALSE, NULL);

// Signal startup event
SetEvent( pThis->m_hStartupEvent );

// Loop until kill event has not been signaled
UINT32 un32Index = 0;
while(WaitForSingleObject( pThis->m_hEventKill, 5) != WAIT_OBJECT_0)
{
// Do pooler job

// Give time to CPU
Sleep(5);
}

// No need this handle anymore
CloseHandle(pThis->m_hEventKill);
pThis->m_hEventKill = NULL;

return FALSE;
}

CPooler::~CPooler(void)
{
// Stop main thread
StopPooling();
}

------------------------------------------------------------------------

Now, always in this DLL, I have implemented a wrapper containing an
array of 100 available CPooler that can be created, started, stopped
and removed. Here is the more important part.

------------------------------------------------------------------------
CPooler* g_Pooler[100];

extern "C" POOLER_LIB_API INT32 __cdecl PoolerCreate(...)
{
// Look for empty place in the array and create the Pooler
int i = 0;
while( i < MAX_POOLER && g_Pooler[i] != NULL ) ++i;

// If empty space was found
CPooler* pTcpPooler = NULL;
if (i < MAX_POOLER)
{
// Create new pooler
pPooler = new CPooler(...);

// Start it !
if ( pPooler->StartPooling() )
{
g_Pooler[in32Result = i] = pPooler;
}
else
{
// Cannot start so delete instance and return error
delete pPooler;
in32Result = -2;
}
}
else
{
// No more space to create a pooler
in32Result = -1;
}

return in32Result;
}
------------------------------------------------------------------------

Now simply to test the class, inside the InitInstance function, I created
a new Pooler and then I delete it just after. Like this

------------------------------------------------------------------------
BOOL CPoolerLibraryApp::InitInstance()
{
CWinAp

Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby Doug Harrison [MVP] » Sun, 03 May 2009 10:18:03 GMT

n Fri, 1 May 2009 16:31:01 -0700, Erakis
< XXXX@XXXXX.COM > wrote:


Hi! Jump directly to the end to see what I think the problem is. Start from
the beginning for some more or less unrelated tips.


You should use AfxBeginThread and CWinThread in an MFC program. See this
page for info on using CWinThread correctly:

http://members.cox.net/doug_web/threads.htm

The logic in StartPooling is rather creative.


That's even more questionable. If the thread is still running after being
asked to exit, it has a bug, and terminating the thread isn't going to help
you find the bug. It may also lead your program to subsequently malfunction
in seemingly unrelated ways.


You're doing a timed wait at the top of the loop, so you don't need to
sleep here. It probably doesn't make any sense to sleep anyway given the
preemptive scheduler.


That's likely your problem...


That spelling makes sense, but it's really "breakpoint".


IIRC, InitInstance and ExitInstance for MFC DLLs are called in DllMain
context, from which it is forbidden to do things like create threads. This
is definitely true for globals, whose ctors and dtors are called from
DllMain. Therefore, you need to initialization and destroy these objects
from EXE context.

--
Doug Harrison
Visual C++ MVP

Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby RXJha2lz » Sun, 03 May 2009 11:17:01 GMT

i Doug,

Sorry for "brake point" :)
First of all I want to thank for your great help, this is really appreciated
:)

If I well understand what you said, I cannot create or stop thread in
InitInstance/ExitInstance ? Why MSDN do not talk about that ? Else, what it
is permit to do and not in those two fuction ?

If I make two function in the DLL ; InitLib() and CloseLib()
So the EXE could load the DLL, call InitLib(), create a new Pooler using the
PoolerCreate() function and at close event of the EXE, the EXE should call
CloseLib()
to stop all the running Pooler and free other resource ?

What if the EXE do not call CloseLib() ? It still will produce strange
behavior ? Leak ?

Because this DLL is a library and anyone could use it so I don't want to
introduce any leak in case of bad use. Do I'm stuck with this limitation ?

Best regards,
Martin

"Doug Harrison [MVP]" wrote:


Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby Joseph M. Newcomer » Sun, 03 May 2009 13:14:14 GMT

ee below...

On Fri, 1 May 2009 16:31:01 -0700, Erakis < XXXX@XXXXX.COM > wrote:

****
This is VERY, VERY, VERY BAD!!!! You must NOT call CreateThread! This is MFC; the ONLY
correct way to create a thread is AfxBeginThread!

It is also completely tasteless to keep the thread ID in a global variable. What is going
to happen if you need two threads? You shouldn't even need the thread ID, let alone keep
it in a global variable! In a sensible universe, you would have a struct/class which had
a thread handle member and a thread ID member, and...whoops, I just reinvented CWinThread,
which is what you should be using!
****
****
If you use AfxBeginThread, you must create it suspended, set the m_bAutoDelete flag to
FALSE, then call CWinThread::ResumeThread. Otherwise, you will not know if the handle is
valid at the point where you do the WFSO.
****
****
The timeout is a silly value, and is apparently a random number. There is no reason to
expect that 1000ms is going to be a sensible value, and consequently there are conditions
under which the thread can start but fail to set the event within 1s, and you are screwed.
****
*****
What about the thread handle? Just because you timed out doesn't mean the thread is
invalid. The thread handle could be valid, but what are you going to do with it if you
return FALSE?
*****
*****
Your choice of name is exceptionally poor; this is not the "main thread", and did you
notice that WFSO can return SEVERAL values, and you test for only ONE of them? Why do you
think this code could be remotely considered viable, let alone correct?
*****
*****
Tasteless in the extreme. If the thread is still running, your program is screwed up and
this will only make the situation much worse.
*****
****
Since this is a static method, it is considered tasteful to put
/* static */ in front of it. Also, you can immediately put yourself back into "C++ space"
so you don't need to keep talking about pThis; see my essay on worker threads on my MVP
Tips site.
****
****
Who can call StopPooling and why do you believe that they will not call it before this
code is executed? This is truly screwed up code. You are depending upon the thread to
create its own shutdown event, but you have the potential to use it before it is created.
Bad design. Rethink it. Why is it autoreset?
****
****
Why is it that you want this thread running continuously, polling for the kill event? Or
did you know that choosing a 5ms wait means this thread will consume as much of the CPU as
possible?
****
There is one very simple rule you can always, ALWAYS be sure of: if your threading system
doesn't work correctly unless you have sprinkled one or more Sleep() calls in it, YOUR
DESIGN IS WRONG. Note that the comment is also nonsense, since you can't "give time" to
the CPU. You can only consume time. Which this thread does, as much as it can possibly
get. Timeouts should be on the order of several hundred milliseconds if your goal is to
minimize CPU waste.

The whole design is deeply and irrecoverably flawed. Rewrite it. From scratch.
****
****
FALSE is a BOOL. The return type is DWORD. return 0 makes sense; return FALSE does not.
*****
****
Why is it you think this destructor is called before ExitInstance is called?
*****
****
Note that you CANNOT call any thread-creation function in the InitInstance of a DLL. This
is documented quite carefully; InitInstance in

Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby Joseph M. Newcomer » Sun, 03 May 2009 16:19:35 GMT

ee below...
On Fri, 1 May 2009 19:17:01 -0700, Erakis < XXXX@XXXXX.COM > wrote:

****
Probably because the MSDN documentation was written for, and has not been updated since,
MFC 1.0 on 16-bit Windows. It is confusing, misleading, incomplete, and in some cases
out-and-out erroneous. See my article which I just finished on my MVP Tips site:

http://www.flounder.com/msdn_documentation_errors_and_omissions.htm#CWinApp::InitInstance
****
****
Yes. It would be erroneous for the caller to fail to call CloseLib
****
****
Probably. Of course, the program is erroneous, so who cares? If the programmer cannot
follow your documentation (and you *are* writing careful documentation to go with this,
aren't you?) then whatever happens is not your fault. You are not responsible for
protecting the user of your DLL from their failure to program correctly.
****
****
You are not "introducing" a leak; the failure of the user of your DLL to call your
CloseLib is the user of your DLL causing a leak because of bad use, and this is not your
responsibility to solve.
joe
*****
Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby Doug Harrison [MVP] » Mon, 04 May 2009 05:37:52 GMT

On Fri, 1 May 2009 19:17:01 -0700, Erakis




MSDN doesn't talk about a lot of things, and that's especially true when
you look at individual articles as opposed to MSDN as a whole. As I recall,
the application object for an MFC DLL (only "non-extension" MFC DLLs have
application objects) is a global variable, globals in DLLs are constructed
and destructed in DllMain context, and InitInstance/ExitInstance are called
as part of app object construction/destruction. For more on DllMain
restrictions, see the DllMain documentation and search MSDN for "DllMain"
and "loader lock".

See also my last four posts in this thread, where I explain a scenario that
causes deadlock when a thread is created in DllMain:

 http://www.**--****.com/ #63906b040cd5e2ff

Finally, there are a lot of MS people who write blogs that contain info you
won't find in MSDN, so that's another source to search.


Yep. I don't see any way to make it fully automatic.

-- 
Doug Harrison
Visual C++ MVP

Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby RXJha2lz » Tue, 05 May 2009 22:29:01 GMT

i,

First of all I want to thank you for your helpfull advise :)

However I have some question that I did not found the answer during week-end.

Suppose I'm using the m_bAutoDelete as you propose and I still need to wait
for thread to be started ; ** Take a look at the WAIT_TIMEOUT condition **

------------------------------------------------------------------------------------
// Create startup event
m_hStartupEvent = CreateEvent(NULL, TRUE, FALSE, NULL);

// Create main thread
m_PoolerThread = AfxBeginThread( PoolerThreadProc, static_cast<LPVOID>( this
), THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED );
m_PoolerThread.m_bAutoDelete = FALSE;

// Resume thread
m_PoolerThread.ResumeThread();

// Check for startup event
switch( WaitForSingleObject( m_hStartupEvent, 1000) )
{
case WAIT_TIMEOUT :
bRet = FALSE; // Thread time-out
// If I well understood the thread could be still be running here ?
// So what should I do ? I think I'd should stop it ? But how to
stop it correctly ?
// Simply called "delete m_PoolerThread" ?
break;

case WAIT_OBJECT_0 :
bRet = TRUE; // Thread sucessfully started
break;
}

// Close startup handle
CloseHandle(m_hStartupEvent);
m_hStartupEvent = NULL;
------------------------------------------------------------------------------------

About Stop pooling function there was already a mechanism to check if it is
called
before the StartPooler function. Sorry for that it is because I minimized
the code
to make it easier to read in this forum.

Best regards,
Martin




"Joseph M. Newcomer" wrote:


Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby Scott McPhillips [MVP] » Wed, 06 May 2009 00:11:17 GMT





If you get this timeout then the thread has not yet started.  That makes it 
impossible to stop it.  Why do you want this timeout?  The code is simple 
enough that the thread should always start.  (But you have no way to know 
how long it might take.)  Instead of passing a timeout value you can pass 
INFINITE.

-- 
Scott McPhillips [VC++ MVP] 


Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby RXJha2lz » Wed, 06 May 2009 00:45:01 GMT

Hi Scott :)

I'm doing that because "Joseph M. Newcomer" advise me to handle all possible 
return value of WaitForSingleObject. WAIT_TIMEOUT is one of the possible 
value.

I admit that the code supplied in this exemple is very simple because I 
wanted to keep the post clearly to get helped.

In fact this class is an ModBus pooler, there is a lot of code but nothing 
is executed  between the thread starting event and the 
SetEvent(m_hStartupEvent).

So in fact is no reason that thread may stuck using INFINITE. But why not 
implement the WAIT_TIMEOUT for good programming as Joseph propose ?

Best regards,









Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby Scott McPhillips [MVP] » Wed, 06 May 2009 02:14:40 GMT






You can only get WAIT_TIMEOUT if you set a timeout.  But if there is no need 
for a timeout set INFINITE and the problem goes away.

-- 
Scott McPhillips [VC++ MVP] 


Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby David Ching » Wed, 06 May 2009 02:27:25 GMT





I agree, there is no need to handle WAIT_TIMEOUT if that cannot be generated 
(which it cannot by specifying INFINITE).  It confuses code to handle 
WAIT_TIMEOUT and providing a good error handling in a case that cannot 
happen (and really there is seldom a really good way of handling a timeout 
since something in another thread has gone very wrong, and it's likely not 
possible to entirely fix that).  So when the reader looks at this code, they 
think there is a possible bug in the WAIT_TIMEOUT case, but this is the 
wrong impression since it won't ever execute.  Whatever gives the code 
reader the correct impression is the correct way to code it.

-- David 


Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby Joseph M. Newcomer » Wed, 06 May 2009 11:23:42 GMT

ee below...
On Mon, 4 May 2009 06:29:01 -0700, Erakis < XXXX@XXXXX.COM > wrote:

*****
In general, putting timeouts in is akin to the use of Sleep() statements in the thread. It
almost always waves a big red flag that says "dangerous design decisions here". Or, as I
tell my students, "Never put a timeout on a WaitFor unless you have a plan for exactly
what you are going to do when it times out, and this plan will work under all possible
timing situations under every possible concurrency scenario". Otherwise, your code is
wrong. I think this design is very bad, and I don't see any reason to waste time trying
to figure out how to debug it. Either the thread starts, or it doesn't. If it starts,
you will get a non-NULL return. If it doesn't start, you will get a NULL. Everything
beyond that is irrelevant. If you care about timeouts, don't do it this way.
joe

****
Of course. It almost certainly could still be running. Or not.
****
****
By having the timeout, you open yourself to these questions. If you don't bother doing
the wait, the issues do not arise.
****
****
This would probably be a fatal error.
****
****
This whole thing is erroneously predicated on the concept that any given wait timeout is
going to make sense. Generally, this should not be a model you use for programming
concurrency. The whole design is wrong.
****
Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby Joseph M. Newcomer » Wed, 06 May 2009 11:35:50 GMT

es, but see my earlier message. You must (a) handle all cases and (b) HANDLE all cases.
That is, you have to account for other errors that can occur, but you must also make sure
that your actual response to the condition is correct. As I pointed out, the presumtion
that the return code can only be WAIT_TIMEOUT is erroneous, but in addition, you must have
a very careful plan as to what happens on a timeout. Your idea that you should kill the
thread is erroneous. You simply signal the thread to stop, should it start up, and go
away. Eventually, the thread will stop, and you will get a notification that it stopped.
But that's an asynchronous event.

One key failure of your design: you have erroneously assumed that you have to represent
sequentiality of execution by sequentiality of syntactic structure. The whole idea that
you can synchronously depend on the thread starting, and you have to actually stop and
wait to see if it started, is the design failure here. I would not waste any effort doing
ANY of this at this point. Call AfxBeginThread, handle the NULL return if it failed, and
otherwise return. At some indefinite point in the future something will happen that will
indicate the thread is running, or it has prematurely stopped. It is the thread's
responsibility to inform about this. You are forcing a sequential model onto a parallel
environment, and this is inherently bad design.

So: you can assume the thread is running if AfxBeginThread returns a non-NULL value. There
is no reason to wait for it, or to time out, or anything like that. If it ever stops
running, it will tell you. How? Because you will have programmed to do so, by any one of
several alternative mechanisms. So the whole idea that you will WaitForSingleObject
already is a failed part of the design. I do not see any reason for it to exist at all.
joe
On Mon, 4 May 2009 08:45:01 -0700, Erakis < XXXX@XXXXX.COM > wrote:

Joseph M. Newcomer [MVP]
email: XXXX@XXXXX.COM
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Re: MFC DLL - ExitInstance hang on WaitForSingleObject

Postby Joseph M. Newcomer » Wed, 06 May 2009 11:36:36 GMT

There is nothing wrong with the design that a total redesign cannot fix.
				joe








Joseph M. Newcomer [MVP]
email:  XXXX@XXXXX.COM 
Web:  http://www.**--****.com/ 
MVP Tips:  http://www.**--****.com/ 

Similar Threads:

1.Releasing a pointer in ExitInstance in a MFC DLL results in an Access Violation

Hello,

I am trying to write a statically linked MFC regular DLL that uses a COM
object. In ExitInstance of this DLL, when I try to release the interface
pointer of the COM object, the DLL gives an access violation. I am testing
the DLL in a statically linked MFC dialog based executable. The development
platform is VS.NET 2003.

Here are the steps:

// MFC DLL

BOOL CCrashTestApp::InitInstance()
{
 CWinApp::InitInstance();

 ::CoInitialize (0);
 HRESULT hr = ::CoCreateInstance (CLSID_XMLDocument, NULL,
CLSCTX_INPROC_SERVER,
  IID_IUnknown, reinterpret_cast <void**> (&m_pUnk));

 return TRUE;
}

int CCrashTestApp::ExitInstance()
{
 m_pUnk->Release ();
 ::CoUninitialize ();

 return CWinApp::ExitInstance();
}

extern "C" __declspec (dllexport) bool __stdcall SayHello ()
{
 ::AfxMessageBox ("Hello", 0, 0);
 return 0;
}

// MFC Test EXE

extern "C" __declspec (dllimport) bool __stdcall SayHello ();

void CCrashTestTestDlg::OnBnClickedButton2()
{
 SayHello ();
}

Now run and close the test executable. You will get an access violation.
This only happens in ExitInstance. If I write two functions Init and Exit to
create and release the interface pointer then everything works. But, I don't
want to provide extra functions.

Please help.

Thanks in advance.

Regards,
Sachin Sharma


2.MFC ActiveX: ExitInstance is only called in debugger

I created a MFC-based ActiveX control. Now, when the browser is closed, I 
want to perform some initialization task in method 'ExitInstance'. This 
works, but only in debugging mode. Otherwise, this method is not called at 
all, when the browser is closed.
What's the reason? Whats the right MFC-method in order to initialize the 
control?

Thanks and regards,
Thomas

3.how to properly initialize an MFC Ext Dll in another MFC Ext Dll

how to properly initialize an MFC Ext Dll in another MFC Ext Dll.

if i just put them together i get a duplicate symbol for DllMain.

should i then remove the DllMain and move the Init/UnInit Code to somewhere else....

thanks

4.Linking a Non MFC dll to a MFC dll

Hi,

I have a non-mfc dll (user.dll).  I need to link it with another
application that accepts input.  I decided to use a MFC dialog box for
that purpose (MyDLL).  I tested the functioning of the MyDll from a
MFC exe application (TestDll).  But when I try to link it to the
non-mfc dll (ie user.dll) the following errors are generated:

-------------------------
F:\xyz\MyDll\MyClass.h(16): error C2146: syntax error : missing ';'
before identifier 'SayHello'
F:\xyz\MyDll\MyClass.h(16): error C2071: 'CMyClass::CString' : illegal
storage class
F:\xyz\MyDll\MyClass.h(16): error C2501: 'CMyClass::CString' : missing
storage-class or type specifiers
F:\xyz\MyDll\MyClass.h(16): error C2061: syntax error : identifier
'CString'
----------------------------

I included the .lib file and header file of MyDll  (i.e MyClass.h) in
the user.dll project. I also declared an object of the dialog class
(CMyClass) in the user.dll.

My problem is in linking the non-mfc dll with mfc dll. The linker does
not recognise any of the MFC classes, CString etc. What lib/files am I
supposed to include and where?

Another question in case there is no solution to the above problem. 
Can I build a non-mfc dll that creates a dialog box and also generates
a .lib file?  I see that except the static link library project, no
other project (win app, console app, dll) generates a .lib file.  How
do I create a .lib file for dll's so that I can link it with the
non-mfc dll?  I read about .def files etc. Can somebody point some
links where I can get examples of converting dlls to .lib?


Thank you very much.   Urgent reply requested.

mp

5.Returning values from mfc-dll to non-mfc dll

Hi,

I am new to mfc and dll.

I have a non-mfc dll that calls a mfc dll.  The mfc dll opens a dialog
box.  I have done this by

1. writing another func (LaunchDialog()) that does not return
mfc-resources or use mfc-rsources as parameteres in the mfc dll
2. CAll LaunchDialog() from the non-mfc dll by including all required
header and lib files.


extern "C" __declspec( dllexport ) int LaunchDialog()
   {
    AFX_MANAGE_STATE(AfxGetStaticModuleState());
    InputDialog indlg;

    return indlg.DoModal();
   }

The problem
--------------
I actually need to pass the value of the text input in the dialog box
back to the calling non-mfc dll.  I am sure there is a documented
method, can any one please tell me how to do it?  Sample code or
pointers to web sites?

Thank you very much.

6. MFC .NET interop problem - Application Hangs

7. ATL composite control hangs in MFC

8. ATL Composite Control hangs in MFC



Return to VC

 

Who is online

Users browsing this forum: No registered users and 8 guest