quote:
Originally posted by raceprouk
So, thinking about it, it's not an issue which API is used (and since they all go to CreateWindowEx anyway).
Both functions call CreateWindowEx to create the dialog, true. But appart from that they do different things. So it is important which function is used.
For example, the DialogBoxParam() function
(modal dialogs) also disables the owner window and it starts its own message loop to get and send messages.
And from MSDN Library: CreateDialogParam()
(modeless dialogs): To support keyboard navigation and other dialog box functionality, the message loop for the dialog box must call the IsDialogMessage() function to determine for which window the message is intedend
(The IsDialogMessage function determines whether a message is intended for the specified dialog box and, if it is, processes the message).
quote:
Originally posted by raceprouk
It's actually a case of the wrong window getting the keypress.
Yes, that's the case in this situation, but it isn't the issue so to speak. The issue is deeper than that: to fix the the bug you need to find why the wrong window gets the keypress.
And this said, and from what I've tested, it isn't so that the wrong window is getting the keypresses as-is. It is more that the keypresses are ignored by the Find dialog and only some are send thru the owner window.
eg: when you focus the Find dialog and press the tab key to go to the next control, nothing will happen. If all keypresses were send to the wrong window, then pressing the tab key would cycle thru the controls on the conversation window (I guess), which it doesn't. Same with accelerator keys and with the enter key, etc...
And since it does work in MSN Messenger 6.x, I guess the problem is more in which is the owner window or something like that (as MSN Messenger 7.x has a whole other makup of its windows and controls (or better the lack of windows))...
dunno, I'm just guessing....
But I
guessknow we must wait for Patchou to clarify this
...
/ 
