Just to followup with an actual fix. After some trials it seems the most effective fix is to hijack the m_themeCommandBars member and set this to custom during non AutoTheme operation. The following makes it all work perfectly.

class CXTPTabClientWndEx : public CXTPTabClientWnd

{

public:

void SetPaintManager(CXTPTabPaintManager* pPaintManager)

{

m_themeCommandBars = xtpThemeCustom;

CXTPTabClientWnd::SetPaintManager(pPaintManager);

}

};

OK, maybe I'm going a bit far here but I'll post anyway in the hope this helps someone or maybe stimulate some sort of fix.

The issue is that when setting a custom paint manager into an XTPTabClientWnd (the tab controller in an MDI app) we get problems on shifting back to a regular paint manager job. Why am I doing this?, well it's to give the user choice of small set of visual themes for the app and one of these is the Whidbey style which is a custom theme job. All well so far but the other styles are simple autothemes derived from the current command bars theme. In principle this is supported just fine.

To pull this off I need to reset the "m_bAutoMode" flag in the class to force it to go back to folling the command bars theme. There's a proper accessor method so I'm guessing this is OK. The problem is that the internal state variable m_themecommandBars is still hanging onto the previous value so doesn't auto update. Try switching from autotheme to customtheme and back to see what I mean and you'll be stuck with the custom theme forever.

The fix, easy enough. Need to invalidate the m_themecommandBars member on switching to a custom theme via the SetPaintManager method. Just like the AutoTHeme member is switched off. Either that or (even better) invalidate in the SetAutoTheme accessor. Overloaded for the time being and it's all tickety boo.

Maybe that helps someone?