Forum

Our project comprises an executable, a couple of MFC extension DLL’s and a few regular MFC DLL’s.  All of these modules use Prof-UIS and the MFC extension DLL’s contain Prof-UIS sub-classed objects for use by the other DLL’s and executable.

We have been having an inordinate number of state problems.  Asserts are constantly triggering down in the MFC code due to these state problems.  It is unclear how to integrate Prof-UIS into a project such as ours, there doesn’t seem to be much if any documentation to give us a direction.  We have tried defining __PROF_UIS_FOR_REGULAR_DLL in the non-extension DLL’s.  Is there something that we’re missing?  How can we make Prof-UIS work with our project?

You need to use the RDE version of Prof-UIS in your MFC regular DLL projects (like in ActiveX projects). These projects should have the __PROF_UIS_FOR_REGULAR_DLL preprocessor symbol defined in the project settings. Besides the RDE extension libraries (not only Prof-UIS as RDE) require an explicit initialization invocation from the regular DLL’s code. In case of Prof-UIS, invoke the following code from the InitInstance() virtual method of the CWinApp-derived class in your regular DLL project:

CExt_ProfUIS_ModuleState::InitExtension(
   AfxGetStaticModuleState()
);

This is essential to let Prof-UIS RDE DLL know which MFC regular host is its owner. After that Prof-UIS will be able to manage MFC state correctly and you will not encounter any assertions. If you are also using ProfAuto RDE library, then initialize it too:

CExt_ProfAuto_ModuleState::InitExtension(
   AfxGetStaticModuleState()
);

Ok, I defined __PROF_UIS_FOR_REGULAR_DLL in all of the regular MFC DLL’s and I called CExt_ProfUIS_ModuleState::InitExtension(AfxGetStaticModuleState()); in the InitInstance() of their corrisponding CWinApp objects.  We’re still experiencing a lot of state assertions.  I verified that we are calling AFX_MANAGE_STATE in the first line all of our exported functions.

Is there a problem including Prof-UIS in an MFC Extension DLL that exports objects which are subclassed from Prof-UIS and then using those subclassed objects in other regular MFC DLL’s and Exe’s?  In searching these message boards I found the following quote from a Prof-UIS rep. "You cannot use MFC-extension DLLs (like Prof-UIS) in other DLLs. The DLLs in question should only be used in EXE programs which, in turn, should also be based on MFC."

The customers problem was not exactly like mine and so I’m not sure if this statement applies or not.

Formerly, Prof-UIS could be used in EXE projects only. More than a year ago we added RDE configurations so that the users can use Prof-UIS in ActiveX/regular DLL projects. Besides, the Frame Features ActiveX control is an MFC extension DLL which instantiates lots of classes derived from Prof-UIS implemented in MBCS and UNICODE Prof-UIS RDE DLL modules. We debugged this ActiveX control with different applications and environments without having any assertions. The Frame Features can be used in Internet Explorer, Office VBA forms, Visual Basic 6.0, Visual J++ 6.0, Visual Basic / J# / C++ / C# .NET 2002 / .NET 2003 / 2005. Prof-UIS 2.50 includes a bug fix with tooltip assertions in toolbars, menus and tab window in RDE builds. We do not know any other assertion bugs and may guess the problem with using RDE in your application is hidden somewhere else. What about sending us some project that demonstrates the problems you mentioned so we can find out what’s wrong?

I’ll see if I can re-create the problems we’re encountering in a dummy project that will be easier to send to you.  Thank you for all the info so far.