C / C++ / MFC

17-May-05 4:16

I am having a difficult time finding my problem in a dll that I am trying to build. This is really my first significant dll. I am trying to export a class from this dll - the dll itself has many classes that support this class, which are not exported, including some that use COM. Some of the supporting classes need to be initialized at the beginning. I am using MFC, but the class being exported is not based on MFC and all the functions in the class use parameters that do not require MFC - so I understand that I do not need to build an MFC extension dll.
I wrote a simple dialog application that included all the classes in the dll, and the dialog with a button that exercises the class that is being exported. Everything works fine. The supporting classes initialize properly, and all the functions in the class to be exported work as expected.
Then I created a project to make the dll with all the same classes. I built the dll and built a new dialog project to test the exported class in dll. The program 'hangs' during initialization that happens in the dll. Here is my problem. When I step through the code, when a function is completed the return statement does not go back to the calling function - it is as though the call stack is somehow corrupted, and there is no next place to step through for the code. How can I find out what is happening? I have never had this particular problem before.

I have another smaller dll that I developed the same way as this which works fine - the basic difference is that this one uses COM to do some ADO, and this dll also has some global variables.

Thanks in advance.

Blake Miller17-May-05 4:55

Blake Miller

17-May-05 4:55

Does this mean your DLL statically links with MFC ?

Did you use the AFX_MANAGE_STATE macro ?
You might need to call this from each member function of your exported class.

Just because you don't directly export a function calling MFC does not mean that you don't still need to enter the correct state for each other function that is exported.

See "Managing the State Data of MFC Modules" in the MSDN.

rajas17-May-05 5:13

17-May-05 5:13

Thanks for the response.

No, I am not statically linking with MFC.

Each of the function that is exported has the AFX_MANAGE_STATE macro in the first line.

I did read the article Managing the State Data of MFC Modules in MSDN, and think that I follow the recommendations.

The problem occurs in a function that is not exported. In fact, it is part of the initialization routine - which iscalled in the InitInstance in of the CWinApp derived class for the dll.

Blake Miller17-May-05 5:40

Blake Miller

17-May-05 5:40

Does the EXE loading the DLL initialize COM ?

If so, does the COM initialization in the EXE occur prior to the initialization in the DLL ?

You might find that your DLL initialization will need to be deferred to an exported 'initialization' call, rather than in the InitInstance, which is basically the same as DLL_PROCESS_ATTACH. As a result of deferral, some class instances dependent upon COM, if they do 'interesting' operations in their constructors, might not be able to remain global, they might have to be created dynamically. The pointers to instances of the classes could be global, but not the instances of the classes themselves.

Basically, you might need to rework in this order, then:
EXE loads DLL (statically, I am presuming, since DLL is linked to EXE)
EXE initializes COM
EXE calls 'init' function exported from DLL
DLL 'init' function 'creates' global objects
...EXE does other work...
EXE calls shutdown function in DLL
DLL frees global objects
EXE uninitializes COM
Windows unloads DLL from EXE address space
EXE exits

You can also get into trouble with COM when creating instances and references to objects that MIGHT not be activated or deleted by the same thread in the EXE as those objects were created.

rajas17-May-05 6:06

17-May-05 6:06

Thanks - I will try this - makes eminent sense. It is fairly straightforward to export an Init function that the .EXE's startup can call.

I had narrowed it to being a COM related issue as the inintialization works if I comment out the COM related code.

rajas17-May-05 10:04

Thread priority management

17-May-05 10:04

Thnaks,

Once I made sure that all initialization and COM calls came after the dll has been loaded - things worked out. I had to instantiate the global objects in an exported Init function subsequent to loading as you had suggested, and have a corresponding ShutDown function that cleaned up the gloabal objects before dll was unloaded. Having the cleanup code as part of unloading the dll frequently led to access violations.

ilgale17-May-05 4:04

ilgale

17-May-05 4:04

In my application I've set the REALTIME_PRIORITY_CLASS.
It manages a worker thread that works at REAL_TIME_PRIORITY_LEVEL
(while the main thread has been set at IDLE_PRIORITY_LEVEL).

The goal'd be to let the worked thread to loop periodically
with its own multimedia timer without being stopped by the
user interface (in example when the user clicks the mouse).
My problem is that when the user stimulates the user interface
(mouse and windows) the worker thread stops for a while.

How can I let my theard loop without being affected by the
user actions ?
Is there a way to let the user interface to have really a very low
priority ?

Thanks a lot !

Bob Stanneveld17-May-05 4:59

Bob Stanneveld

17-May-05 4:59

Hello,

You can try to set the prioity of your process to a higher level. Windows will give your process a bigger timeslice. Your process will give most of the time to your worker thread.

But be carefull with setting your process priority to realtime. If you do this, Windows will give almost all the time to your process and other applications could 'freeze' because there is no time left..

Hope this helps.

I also got the blogging virus..[^]

ilgale17-May-05 5:16

ilgale

17-May-05 5:16

Thanks for your help but, as I've written in my first post,
I think to have already done what you say. I've used the following instructions in the InitInstance function of the App class:

SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
SetThreadPriority(THREAD_PRIORITY_IDLE);

Then I've used the next call in my worker thread:

SetThreadPriority(THREAD_PRIORITY_TIME_CRITICAL);

Is there something more to do ?

Bob Stanneveld17-May-05 22:24

Bob Stanneveld

17-May-05 22:24

Hello,

There could be many reasons for your worker thread to stop for a while. A few of these reasons could be:
<list>

Your processor is slow

Your GUI thread synchronizes access to some object with your worker thread using synchronization objects, that block your worker thread

The library that you are using is not very optimized

...
It should not be neccesary to set your process priority to realtime. If you don't let your worker thread run in it's own seperate process, windows ensures that it will always be interupted when the user stimulates the GUI...

I also got the blogging virus..[^]

ilgale17-May-05 23:04

ilgale

17-May-05 23:04

Ok, so... as I was thinking the only way to really separate a thread by the user interface is to create it in a separate process created by the main application.

Thanks a lot for your advice !!