stergios@portia.Stanford.EDU (Stergios) (06/18/91)
Hi Gang, got a question/problem I hope you can help me with. SYNOPSIS: Multiline edit control causes dialog box to go away when the return key is pressed. DESCRIPTION: I have a multiline edit crontrol in a dialog box. The flags for the edit crontrol appearing in the resource are: ES_MULTILINE | WS _TABSTOP | WS_BORDER | WS_VISBLE | WS_CHILD Nothing fancy about that. I have tried adding ES_AUTOVSCROLL. The multiline edit would then automatically scroll when it was time to wordwrap, as one would expect, but still exhibit the same behaviour when the return key was pressed. Could it be that a dialog default push button listens on the input stream and accepts all returns no matter where the input focus is? Obviously, I do not completely understand dialogs. Can some clear things up for me? Thanks, Stergios Marinopoulos stergios@kt22.Stanford.EDU -- Stergios Marinopoulos stergios@kt22.Stanford.EDU
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (06/19/91)
I don't think you have a problem - it sounds like Windows and your program are both working as expected. Users will have to use the tab key to leave the edit field, not the return key (which ordinarily causes the dialog box to be accepted). Terrell
ssl@hpkslx.mayfield.HP.COM (SSL Guest User) (06/20/91)
Hi, You mentioned a push button... If you have a default push button in the same dialog, then pressing return (while the input focus is anywhere in the dialog) will cause the buttons event to be processed. That probably explains the dialogs disappearance. But you probably already know that... Best of luck, Thomas
bonneau@hyper.hyper.com (Paul Bonneau) (06/20/91)
In article <STERGIOS.91Jun18103411@kt22.Stanford.EDU> stergios@kt22.Stanford.EDU writes: > > >Hi Gang, got a question/problem I hope you can help me with. > >SYNOPSIS: > Multiline edit control causes dialog box to go away when the >return key is pressed. > >DESCRIPTION: > I have a multiline edit crontrol in a dialog box. The flags >for the edit crontrol appearing in the resource are: > > ES_MULTILINE | WS _TABSTOP | WS_BORDER | WS_VISBLE | WS_CHILD > >Nothing fancy about that. I have tried adding ES_AUTOVSCROLL. The >multiline edit would then automatically scroll when it was time to >wordwrap, as one would expect, but still exhibit the same behaviour >when the return key was pressed. > >Could it be that a dialog default push button listens on the input >stream and accepts all returns no matter where the input focus is? > >Obviously, I do not completely understand dialogs. Can some clear >things up for me? > You're right. <return> activates the default PushButton. It is interpreted by the dialog manager just after GetMessage(), and transformed into a button push (if there is a default PushButton). So the keyboard focus is not used. The translation is done by IsDialogMessage() (which is called internally for modal DialogBoxes). The standard way to enter a new-line into a MLE is to use <ctrl>-<enter>. If you wish to be nonstandard, you could make the dialog modeless and look for WM_KEYDOWN messages from GetMessage(). If you get one for a VK_RETURN, and the MLE of the dialog has the focus, *send* it a WM_CHAR of VK_RETURN and don't call IsDialogMessage(). If you want a modal dialog, just create a routine with a message pump that disables the owner window on entry and reenables on exit. It creates a modeless dialog, but as far as your app is concerned will behave modally. This is much easier than installing a WindowsHook of type WM_MSGFILTER. cheers - Paul Bonneau.
lk@cbnewsj.att.com (lisa.a.krauth) (06/20/91)
In article <1991Jun19.185843.2195@hyper.hyper.com>, bonneau@hyper.hyper.com (Paul Bonneau) writes: > In article <STERGIOS.91Jun18103411@kt22.Stanford.EDU> stergios@kt22.Stanford.EDU writes: > > > > > >Hi Gang, got a question/problem I hope you can help me with. > > > >SYNOPSIS: > > Multiline edit control causes dialog box to go away when the > >return key is pressed. > > > >DESCRIPTION: > > I have a multiline edit crontrol in a dialog box. The flags > >for the edit crontrol appearing in the resource are: > > > > ES_MULTILINE | WS _TABSTOP | WS_BORDER | WS_VISBLE | WS_CHILD > > > >Nothing fancy about that. I have tried adding ES_AUTOVSCROLL. The > >multiline edit would then automatically scroll when it was time to > >wordwrap, as one would expect, but still exhibit the same behaviour > >when the return key was pressed. > > > >Could it be that a dialog default push button listens on the input > >stream and accepts all returns no matter where the input focus is? > > > >Obviously, I do not completely understand dialogs. Can some clear > >things up for me? > > > You're right. <return> activates the default PushButton. It > is interpreted by the dialog manager just after GetMessage(), > and transformed into a button push (if there is a default > PushButton). So the keyboard focus is not used. The > translation is done by IsDialogMessage() (which is called > internally for modal DialogBoxes). > > The standard way to enter a new-line into a MLE is to use > <ctrl>-<enter>. If you wish to be nonstandard, you could > make the dialog modeless and look for WM_KEYDOWN messages > from GetMessage(). If you get one for a VK_RETURN, and > the MLE of the dialog has the focus, *send* it a WM_CHAR of > VK_RETURN and don't call IsDialogMessage(). If you want a > modal dialog, just create a routine with a message pump > that disables the owner window on entry and reenables on > exit. It creates a modeless dialog, but as far as your > app is concerned will behave modally. This is much easier > than installing a WindowsHook of type WM_MSGFILTER. > > cheers - Paul Bonneau. With version 2.1 of the SDK you did not need to press ctrl-enter to move to the next line. The enter key would move you to the next line in the editbox. Is this (ctrl-enter) something new in 3.0? I have also been struggling with the MLE trying to get it to behave as it did with version 2.1 of the SDK. Can anyone shed some more light on this subject? Why has the behavior changed? Lisa Krauth att!lzatt!lak
brianw@spider.co.uk (Brian Wyld) (06/20/91)
In article <STERGIOS.91Jun18103411@kt22.Stanford.EDU> stergios@kt22.Stanford.EDU writes: > > >Hi Gang, got a question/problem I hope you can help me with. > >SYNOPSIS: > Multiline edit control causes dialog box to go away when the >return key is pressed. > >DESCRIPTION: > I have a multiline edit crontrol in a dialog box. The flags >for the edit crontrol appearing in the resource are: > > ES_MULTILINE | WS _TABSTOP | WS_BORDER | WS_VISBLE | WS_CHILD > >Nothing fancy about that. I have tried adding ES_AUTOVSCROLL. The >multiline edit would then automatically scroll when it was time to >wordwrap, as one would expect, but still exhibit the same behaviour >when the return key was pressed. > >Could it be that a dialog default push button listens on the input >stream and accepts all returns no matter where the input focus is? > >Obviously, I do not completely understand dialogs. Can some clear >things up for me? > As Paul Bonneau said, Win 3 takes RETURN as default button. <CTRL><RETURN> puts in a return. You can change this behaviour by subclassing the edit control. I have code to do this (email me if you want it) or simply subclass, catch the VK_RETURN, fiddle the keyboard map (Get/SetKeyboardState) to say CTRL is pressed, call the default proc and then refiddle the map back again. Slightly more intuitive.... brian wyld <brianw@spider.co.uk : Spider Systems Ltd, Stanwell St, Edinburgh > <My opinions, ok? : 031 554 9424 : That's SCOTLAND, pal >
bonneau@hyper.hyper.com (Paul Bonneau) (06/21/91)
In article <1991Jun19.215304.13141@cbnewsj.att.com> lk@cbnewsj.att.com (lisa.a.krauth) writes: >In article <1991Jun19.185843.2195@hyper.hyper.com>, bonneau@hyper.hyper.com (Paul Bonneau) writes: >> You're right. <return> activates the default PushButton. It >> is interpreted by the dialog manager just after GetMessage(), >> and transformed into a button push (if there is a default >> PushButton). So the keyboard focus is not used. The >> translation is done by IsDialogMessage() (which is called >> internally for modal DialogBoxes). >> >> The standard way to enter a new-line into a MLE is to use >> <ctrl>-<enter>. If you wish to be nonstandard, you could >> make the dialog modeless and look for WM_KEYDOWN messages >> from GetMessage(). If you get one for a VK_RETURN, and >> the MLE of the dialog has the focus, *send* it a WM_CHAR of >> VK_RETURN and don't call IsDialogMessage(). If you want a >> modal dialog, just create a routine with a message pump >> that disables the owner window on entry and reenables on >> exit. It creates a modeless dialog, but as far as your >> app is concerned will behave modally. This is much easier >> than installing a WindowsHook of type WM_MSGFILTER. > >With version 2.1 of the SDK you did not need to press ctrl-enter to >move to the next line. The enter key would move you to the next line >in the editbox. Is this (ctrl-enter) something new in 3.0? I have >also been struggling with the MLE trying to get it to behave as it did >with version 2.1 of the SDK. Can anyone shed some more light on this >subject? Why has the behavior changed? > Sorry for the misunderstanding. Even in win 3.0, a plain simple <enter> will insert a new-line into the MLE. The problem is that the dialog manager will never let it happen. As for <ctrl>-<enter>, it is not an implementation restriction but rather what Microsoft's own windows apps do (for example Edit Summary Info in W4W). You can use just plain old <enter> if you want, if you are willing to go through the hoops I described. Also, I don't think the behaviour *has* changed. I seem to recall that hitting <enter> in a win 2.x dialog would always activate the Default PushButton, regardless of the keyboard focus. cheers - Paul Bonneau.
lk@cbnewsj.att.com (lisa.a.krauth) (06/21/91)
> In article <1991Jun19.215304.13141@cbnewsj.att.com> lk@cbnewsj.att.com (lisa.a.krauth) writes: > >With version 2.1 of the SDK you did not need to press ctrl-enter to > >move to the next line. The enter key would move you to the next line > >in the editbox. Is this (ctrl-enter) something new in 3.0? I have > >also been struggling with the MLE trying to get it to behave as it did > >with version 2.1 of the SDK. Can anyone shed some more light on this > >subject? Why has the behavior changed? > > > >In article <1991Jun19.185843.2195@hyper.hyper.com>, bonneau@hyper.hyper.com (Paul Bonneau) writes: > Sorry for the misunderstanding. Even in win 3.0, a plain > simple <enter> will insert a new-line into the MLE. The > problem is that the dialog manager will never let it happen. > As for <ctrl>-<enter>, it is not an implementation > restriction but rather what Microsoft's own windows apps do > (for example Edit Summary Info in W4W). > > You can use just plain old <enter> if you want, if you are > willing to go through the hoops I described. Also, I don't > think the behaviour *has* changed. I seem to recall that > hitting <enter> in a win 2.x dialog would always activate > the Default PushButton, regardless of the keyboard focus. > > cheers - Paul Bonneau. Maybe I still do not understand what you are saying, but this is my experience: I wrote an application using the 2.1 SDK. The application has a dialog box that has a multiline autoscroll editbox and a 2 pushbuttons (OK, CANCEL). In the 2.1 application if I gave focus to the editbox, typed in a line of text and hit return, I would move to the next line in the editbox. When I ported the code to version 3.1 of the SDK, the editbox no longer worked this way. Now when I enter a line of text in the editbox and hit enter, it looks like the OK button gets depressed, but the code to be executed when the OK is depressed does not execute. I must explicitly use the mouse to press the OK button to make the dialog box go away. So it seems to me that something has changed, and it almost seems like a bug. I sure hate losing functionality with a new release of software. I'm going to be even more unhappy if I have to write new code to give me what I got for free before. Please, someone tell me this isn't true! Lisa Krauth att!lzatt!lak
bonneau@hyper.hyper.com (Paul Bonneau) (06/22/91)
In article <1991Jun20.144858.11588@spider.co.uk> brianw@spider.co.uk (Brian Wyld) writes: >As Paul Bonneau said, Win 3 takes RETURN as default button. <CTRL><RETURN> >puts in a return. > >You can change this behaviour by subclassing the edit control. I have code >to do this (email me if you want it) or simply subclass, catch the >VK_RETURN, fiddle the keyboard map (Get/SetKeyboardState) to say CTRL is >pressed, call the default proc and then refiddle the map back again. > This is not true. The MLE *will* move down a line *without* the control key pressed. Fiddling the keymap is unnecessary. I wrote the following case to test it: CreateWindow((LSZ)"edit", lszNull, WS_POPUP | WS_CAPTION | WS_SYSMENU | ES_MULTILINE | WS_VISIBLE | ES_AUTOVSCROLL, 0, 0, 200, 200, hwndAppMainWindow, hmnuNull, hinstApplication, 0L); The result was a MLE in a popup which had no problem with <return>. The problem is that the dialog manager is eating the <return>, and activating the default button. Using <ctrl>-<return> prevents the dialog manager from performing this translation. cheers - Paul Bonneau.
epperson@adobe.COM (Mark Epperson) (06/22/91)
Subclass the edit control and translate the <enter> into <ctrl-enter> this works fine. Mark Epperson