0

I'm trying to debug this problem in a library where a set of controls are not being updated to be disabled. I've drilled down to a point where I've hit a black box. A mfc120ud.dll!CCmdUI::DoUpdate() call will then call CCmdUI::Enable(). It'll then go through a bunch of calls one through ntdll.dll and 4 through user32.dll for which I have no source for and then sometimes stick its head our coming back to mfc123ud.dll or sometimes not.

I don't know why the WM_PAINT message gets invoked sometimes. Does anyone know?

call stack

Adrian
  • 10,246
  • 4
  • 44
  • 110
  • Your question is pretty broad. Can you add specifics to provide some kind of context to your problem? – rrirower Jan 09 '15 at 18:56
  • 1
    `WM_PAINT` is a low-priority message. It is generated by the system when the invalid area is non-empty, and there are no higher priority messages in the message queue (input messages, posted messages). – IInspectable Jan 09 '15 at 21:58

1 Answers1

0

Your call stack shows the reason.

CCmdUI::DoUodate finally calls CCmdUI::Enable.

Look into the CCmdUI::Enable code of the MFC. There are cases that WM_NEXTDLGCTL is called or EnableWindow. WM_NEXTDLGCTL may cause a focus change. It depends how the controls will handle this message. It is possible that they directly call UpdateWindow or RedrawWindow to reflect changes to the UI, instead of just calling Invalidate(Rec). There may be a control inside your ribbon that receives the WM_PAINT message.

The call to EnableMenuItem should be safe and I am sure that it doesn't cause a WM_PAINT call.

xMRi
  • 14,982
  • 3
  • 26
  • 59