CDXUTDialogResourceManager cannot be deleted and recreated.

This bug took three days to track down. It's nasty!

The sympthom was that every time I moved the D3D window from my primary monitor to my secondary monitor or vice-versa, D3DXCreateFont() would have a protection fault. Eliminating all of the fonts in my code reveals that other D3D functions were also throwing protection faults. It turns out that the fault has nothing to do with D3D, but is instead in ~CDXUTDialogResourceManager() of all places!

What happens is that the destructor calls two obscene little functions: CUniBuffer::Unitialize() and CDXUTIMEEditBox::Unitialize() whichunloads some .dlls!!! These uninitializers are not mirrors of functions that were in the constructor. The dlls were loaded by the CUniBuffer constructor and the CDXUTIMEEditBox respectively. Ugly.

I found this bug because I was inadvertantly destructing and recreating a context class that had my CDXUTDialogResourceManager as a member. That should work fine, if you don't mind unloading .dlls in the middle of it!

One fix is to declare your one and only DialogResourceManager in global space (think: 1980's code) the other is to call CUniBuffer::Initialize() and CDXUTIMEEditBox::Initialize() in the DRM constructor, but you'll have to add a reference counter or some other hack to make sure that the number of initializations balances out before uninitializing. The best solution is not to unload .dlls in a destructor.

I hope my comments about this oversite can save someone else the three days I've just lost.

Thanks,

MikeW, CEO of CodeFire Studios.

[1610 byte] By [OnlineGameGuy] at [2008-2-6]
# 1

You seem to talk about old code. Do you still use D3D9 or is this a problem after porting to D3D10?

RalfKornmann at 2007-8-31 > top of Msdn Tech,Game Technologies: DirectX, XNA, XACT, etc.,Direct3D 10...