Shoutbox

Well when the "find" is up (ctrl+f) then hit esc it will close the conversation

steps to reproduce:
1) hit ctrl+f
2) hit esc

results:
coversation window is closed.

intended result:
find popup is ment to close leaving the conversation window in focus.


Windows Version: Windows XP, 5.01.2600
Messenger Client Version: 7.0.0816
Messenger Plus! Version: 3.61.0145

Bug confirmed. This doesn't happen with e.g the Quote Sender.

Windows Version: Windows XP Professional 5.1.2600 SP2 build 2600
Messenger Client Version: 7.5.0311
Messenger Plus! Version: 3.61.145

Bump. What about the problem. Please dont forget about it

quote:

---

Originally posted by Mattike
Bug confirmed. This doesn't happen with e.g the Quote Sender.

Windows Version: Windows XP Professional 5.1.2600 SP2 build 2600
Messenger Client Version: 7.5.0311
Messenger Plus! Version: 3.61.145

---

The bug was confirmed by quite a few people before posting it here

The bug doesn't happen in MSN Messenger 6.x


In MSN Messenger 6.x (where the bug doesn't happen) the keyboard input is as it is intended and keys work as they are intended (tab, amersands, enter, esc, etc)...

In MSN Messenger 7.x (where the bug occurs) the find dialog does not recieve the keyboard input (tab, amersands, enter, esc, etc), instead the input is directed to the convo window (and thus esc closes the convo, etc...).


--------

quote:

---

Originally posted by Mattike
This doesn't happen with e.g the Quote Sender.

---

Because  the Quote Sender Dialog and the Find Dialog are two different kind of dialogs and can't be compared like that. One is modal (Quote Sender) the other is modeless (Find Dialog). Both types work in a total different way.

quote:

---

Originally posted by John Anderton
Bump. What about the problem. Please dont forget about it

---

Why bumping after a few hours only to say "don't forget about it"?

quote:

---

Originally posted by CookieRevised

In MSN Messenger 7.x (where the bug occurs) the find dialog does not recieve the keyboard input (tab, amersands, enter, esc, etc), instead the input is directed to the convo window (and thus esc closes the convo, etc...).

---

True.

I reported this to Patchou during beta testing, and Patchou replied that he had already been aware of this bug... unfortunately, just as what Cookie said, there is currently no fix or workaround

quote:

---

Originally posted by CookieRevised
The bug doesn't happen in MSN Messenger 6.x


In MSN Messenger 6.x (where the bug doesn't happen) the keyboard input is as it is intended and keys work as they are intended (tab, amersands, enter, esc, etc)...

In MSN Messenger 7.x (where the bug occurs) the find dialog does not recieve the keyboard input (tab, amersands, enter, esc, etc), instead the input is directed to the convo window (and thus esc closes the convo, etc...).

---

Oww... okay then...

quote:

---

Originally posted by CookieRevised

quote:

---

Originally posted by Mattike
This doesn't happen with e.g the Quote Sender.

---

Because  the Quote Sender Dialog and the Find Dialog are two different kind of dialogs and can't be compared like that. One is modal (Quote Sender) the other is modeless (Find Dialog). Both types work in a total different way.

---

I've got both modal and modeless dialogs, and they always get Esc and Tab as intended, along with accelerators, which the Find dialog doesn't get.

Does Patchou use DialogBoxParam (like me), or CreateWindow(Ex)/CreateDialog?

quote:

---

Originally posted by raceprouk
Does Patchou use DialogBoxParam (like me), or CreateWindow(Ex)/CreateDialog?

---

DialogBoxParam() is used to create modal dialogs...

CreateDialogParam() is used to create modeless dialogs...

In other words, Patchou uses both (DialogBoxParam() for the modal dialogs and CreateDialogParam() for the modeless dialogs).

PS: You probably know this already too, but  seeing as you said

quote:

---

"DialogBoxParam" or "CreateWindowEx aka CreateDialog"

---

both the
functions are actually nothing more than kind of "stubs" (for the lack of a better word) for the CreateWindowEx() function. Thus not only CreateDialogParam(), but DialogBoxParam() also.

I see.
Anyway, the keypress should go to the window with the focus, yes? So, thinking about it, it's not an issue which API is used (and since they all go to CreateWindowEx anyway). It's actually a case of the wrong window getting the keypress.

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 ...