开发者

dialog procedure message sequencing

开发者 https://www.devze.com 2023-03-22 13:55 出处:网络
I got into some trouble I think caused by message sequencing in a dialog procedure. Trying to avoid more global variables, I added a WM_USER message to my dialog to set the color of a control.The mess

I got into some trouble I think caused by message sequencing in a dialog procedure. Trying to avoid more global variables, I added a WM_USER message to my dialog to set the color of a control. The message handling code simply stored the COLORREF in a static variable. In the INITDIALOG, I did a SendMessage(hDlg,WM_User...) (to the dialog itself) followed by a SetDlgItemText for an static control in the dialog. WM_CTLCOLORSTATIC message handling code sets the color, background color, and font for the static control. Everything seemed to work as expected until I overlaid the app with another from the task bar. When I re-established the app, the part of the static control that was hidden changed from the desired color to black. Note that the font size also changed by the WM_CTLCOLORSTATIC message was not affected. There is no way for this information to be regenerated so the windows dialog processing must save it somewhere. This, of course is impossible to debug because of interactions between the app and Visual Studio. When I replaced the SendMessage method of sending the color simply setting a global variable, the problem开发者_运维技巧 disappeared.

So, I'm curious about the messages that get sent to the dialog and the order in which they are sent? The MSDN says SendMessage does not return until the message has been processed by the window. So I guess the messages must look like this

WM_INITDIALOG starts

  WM_USER starts             (caused by the SendMessage call)
  WM_USER ends

  WM_CTLCOLORSTATIC starts   (caused by the SetDlgItemText call)
  WM_CTLCOLORSTATIC ends

WM_INITDIALOG ends

Meanwhile the static control is processing the WM_SETTEXT message before and after the WM_CTLCOLORSTATIC messages. I suppose other message such as WM_COMMAND/EN_CHANGE also get generated and processed.

If that's the case, I don't see what caused my problem or how it was fixed by eliminating the SendMessages.


It turns out that something in windows was also sending WM_USER messages, changing to WM_APP fixed my problem. I am still curious as to the sequencing of messages in case anyone wants to respond to that

See WM_USER obsolete, use WM_APP

0

精彩评论

暂无评论...
验证码 换一张
取 消