Forum

Hi, this has been driving me mad for a week or two, but our view keeps repainting repeatedly.  I eventually tracked it down to the following sequence of events:

- The WM_MDIREFRESHMENU message keeps being sent to the MDI tabs window.

- ProfUIS catches this in CExtTMWI::OnHookWndMsg() and sets the __EXTTAB_MDI_UPDATE_TIMER_ID timer.

- The timer event is handled in CExtTMWI::WindowProc(), and calls _SyncAllItems()

- Downstream from this I think RecalcLayout() gets called and that probably causes a repaint of the current view itself.

It’s only in some types of view we have that this happens.  My guess is that I redraw and the window is marked as valid, but the timer is set before this and acted on after this, causing a loop.

First, why does WM_MDIREFRESHMENU ever cause a redraw of the view?  Especially when nothing in the menu has changed.  I don’t even know why that event keeps arriving.

Second, why is a timer used at all??  It seems a really bad way to delay an update till there’s a spare moment.  Isn’t OnIdle() the place for this?  Seems like a much safer way to do things.

Any other thoughts about why this is happening?  Currently I am overriding OnHookWndMsg() to catch the WM_MDIREFRESHMENU event and ignore it, and the MDI tabs bar menu still seems to remain valid, but I’m sure this is just hiding the real problem rather than fixing it.  And since doing it I have other problems, but not sure if they’re related.

Thanks,

Rob.

The Spy++ utility can help you and us to find out what’s really wrong. You can spy all the window message in the main UI thread of your application. There must be something what makes this infinite repainting occur. Something like timer based code which repaints parts of UI independently from whether repainting is needed or not. Please run your app, make it infinite repainting and put the code like this into any of methods which are invoked in this infinite magic:

if( CExtPopupMenuWnd::IsKeyPressed( VK_CONTROL ) )
{
int nNumericVariable = 0; nNumericVariable; // Please set breakpoint to this line of code.
}

The code snippet above will break into debugger if the Ctrl key is pressed. You can put it into your project or into Prof-UIS source code. Then you can start the infinite repainting show and Ctrl anytime. This will stop the app execution at the breakpoint. Now you can copy the content of the Call Stack window and show it to us. Please try to do this experiment several times and show us the most detailed and long call stack listing.

As I said the repainting is invoked during ProfUIS’s handling of the __EXTTAB_MDI_UPDATE_TIMER_ID timer event, which in turn is invoked when the WM_MDIREFRESHMENU message is handled.  I have found now though that it was our own code sending too many WM_MDIREFRESHMENU messages.  I have worked around that and it fixes the problem, although it’s maybe still a little odd that when ProfUIS handles that message it causes the view to be redrawn, even when the menu hasn’t actually changed.

For now though, I seem to have fixed this one,

Thanks,

Rob.