Use SetTheme in DLL

the error says

debug assertion failed

in xtthememanager.cpp

i debug the code found that

the error happened in

CXTThemeManager::~CXTThemeManager()
{
 POSITION pos = m_mapDefaultFactories.GetStartPosition();
 void* pThemeFactoryClass;
 CXTThemeManagerStyleFactory* pFactory = 0;
 while(pos)
 {
  m_mapDefaultFactories.GetNextAssoc(pos, pThemeFactoryClass, (void *&)pFactory);
  delete pFactory;
 }

 ASSERT(m_factoryList.m_pHead == 0); //here
 m_factoryList.RemoveAll();
}

2005-08-18_061524_demo.zip

Check sample. DOn't see any assert errors :(

I had a similar problem with version 8.6, which has to do NOT with when the DLL that "new"ed the specific custom theme, but with WHERE the constructor/destructor code of the custom theme is located.  In my case, the custom theme code is IN A DLL - this is BAD, as I will describe below.

The "global theme manager" is a static? global? object that gets "free"ed when the .EXE shuts down (I can't remember the specific call, but basically the C++ startup/shutdown code calls the destructors of all "global/static" objects at shutdown).  Regardless, the .DLL that has the code for the custom theme is now UNLOADED when the global theme manager is destroyed.  What's the big deal?  The deal is that the destructor of a theme is VIRTUAL, hence when the code in the global theme manger that deletes this custom theme is CALLED, the DLL that this virtual function pointed to is now GONE!

The "correct" fix is to implement ALL custom themes in the main .EXE, but I wanted mine in a DLL for reasons that are only valid to me, cuz sometimes I like it that way  

My fix for shutting down with custom themes implemented in a DLL, though crude, works.  "Standard" themes do not have this problem because their code is still "in memory" (even though we use the XTP as a DLL?!?).  Anyway, all I do is call CXTPPaintManager::SetTheme(xtpThemeOfficeXP) first thing in the OnDestroy of my main CFrameWnd dervied window. This causes the current theme to be swapped out with one of the "predefined" themes at the last possible moment. The previous theme's destructor is called while its code is still loaded, hence no crash at shutdown!