AFX_MODULE_STATE with USRDLL vs AFXDLLs

Will someone please explain how "Module state" is maintained
differently when using a USRDLL vs an AFXDLL? For example,
for a USRDLL, when an CWinApp's InitInstance is called,
the runtime automatically switches the state, but when I
use the shared MFC DLL, I must call AFX_MAINTAIN_STATE(...)
at the beginning of all exported functions.

I don't really understand what is going on with the state, especially when multithreading comes into the picture.
For example, if in an USRDLL I call AfxBeginThread and I'm
linking to shared MFC DLL, how does module state come into play?
rachelsAsked:
Who is Participating?
 
doronhConnect With a Mentor Commented:
OK, this is a complex issue, but here are a couple of resources that will explain the MFC universe of dll's.  The very basic gist of all these AFX_MANAGE macros is to handle resources, different threads, and ownership.

1) In VC Books online, an article titled Managing the State Data of MFC Modules. It can be found in
Visual C++ Books
 MFC 4.2 (4.x depending on your version)
  Programming with MFC Encyclopedia
   Managing the State Data of MFC Modules
2) Tech article #58:  MFC Module State Implementation
   
Here is the first paragraph from resource #1:
This article discusses the state data of MFC modules and how this state is updated when the flow of execution (the path code takes through an application when executing) enters and leaves a module. Switching module states with the AFX_MANAGE_STATE and METHOD_PROLOGUE macros is also discussed.
 
Note   The term "module" here refers to an executable program, or to a DLL (or set of DLLs) that operate independently of the rest of the application, but uses a shared copy of the MFC DLL. An OLE control is a typical example of a module.
 
As shown in Figure 1, MFC has state data for each module used in an application. Examples of this data include: Windows instance handles (used for loading resources), pointers to the current CWinApp and CWinThread objects of an application, OLE module reference counts, and a variety of maps that maintain the connections between Windows object handles and corresponding instances of MFC objects. However, when an application uses multiple modules, the state data of each module is not application-wide. Rather, each module has its own private copy of the MFC’s state data.

The difference between USRDLL and AFXDLL is who the dll is targeted for.  An AFXDLL is made for use w/in VC++ only.  A USRDLL is created for the non VC users out there (VB, Delphi, straight C).  If your dll is going to be used w/in VC only, then create an AFXDLL.

Hopefully this is enough to get a strong foothold.  Whenever I need to figure things like this out I first search through the on-line help.  Also, I highly highly recommend getting MSDN (MS Developers Network)....can't live w/out it really.

doron
0
 
codediscussCommented:
but WHY the state data of each module is not application-wide?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.