Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!cbnewsk!cbnewsj!lk
From: lk@cbnewsj.att.com (lisa.a.krauth)
Newsgroups: comp.windows.ms.programmer
Subject: Re: Multiline Edit Control in Dialog
Summary: SDK version 2.1 worked differently
Message-ID: <1991Jun19.215304.13141@cbnewsj.att.com>
Date: 19 Jun 91 21:53:04 GMT
References: <STERGIOS.91Jun18103411@kt22.Stanford.EDU> <1991Jun19.185843.2195@hyper.hyper.com>
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 57

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