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
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]
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,
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]
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
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/
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
Users browsing this forum: No registered users and 8 guest