Forum

Hi,

I discovered that CExtNcFrameImpl::NcFrameImpl_PostWindowProc is, in some situations, called recursively by WB when the message is WM_WINDOWPOSCHANGING and using a skin with translucency making whole s.o. really slow.

One could think that WB makes a window to receive another WM_WINDOWPOSCHANGING while processing a WM_WINDOWPOSCHANGING and prof-uis only checks the presence of DWM. I don’t know which, wb or prof-uis hook WindowProc first but at some time the app breaks with a general protection fault (not an stack overflow... strange)

Time ago, I sent first a mail to tech support in stardock and then I could discover where is the problem.

Best regards,
Mauro.

Hi,

Previously I had some issues with wb5 (another topic I created last year).

But I could resolve the problem temporary by adding a flag to prevent recursion within WM_WINDOWPOSCHANGING by calling DefWindowProc when recursion occurs.

For e.g. when using Leo (StarDock design theme) and my pseudo-fix, the application runs fine but wb overpaints the non-client area with the skin.

Prof-UIS disables some skinning when dwm is active. I wish to know if there is any way to know if WB is active. I wrote to Stardock without success :(

Best regards,

Mauro H. Leggieri

The CExtNCW template class simply implements the CWnd::WindowProc() virtual method and does not introduces any thread hooks nor window procedure replacements. We have WB5 license and we will upgrade to WB6 or purchase it for checking this issue. At least WB5 is not very friendly to any MFC based applications because its non-client area skinning code runs timers aggressively what causes unwanted MFC’s command updating queries for toolbars and menus.