[PATCH] user32: Handle VK_RETURN KeyDown events more properly in EDITcontrols.

[Lei Zhang]

On Sat, Apr 19, 2008 at 4:05 AM, Reece Dunn <msclrhd at googlemail.com> wrote:
>  Reading the MSDN documentation for the behaviour of ES_MULTILINE, it
>  says "When the multiline edit control is in a dialog box, the default
>  response to pressing the ENTER key is to activate the default button.
>  To use the ENTER key as a carriage return, use the ES_WANTRETURN
>  style."
>
>  Therefore, I think your patch is incomplete, especially the part about
>  the ES_WANTRETURN style. As such, you will need tests to verify this.
>
>  In response to the enter key there are three behaviours:
>  1.  the default push button is not activated; the edit contents is unchanged.
>  2.  the default push button is activated; the edit contents is unchanged.
>  3.  the default push button is not activated; the edit contents has a
>  new line inserted at the current cursor position.
>
>  You have the following configurations with their associated behaviours:
>   *  an edit control in a dialog without ES_MULTILINE and without
>  ES_WANTRETURN: behaviour (2).
>   *  an edit control in a dialog with ES_MULTILINE and without
>  ES_WANTRETURN: behaviour (2).
>   *  an edit control in a dialog with ES_MULTILINE and with
>  ES_WANTRETURN: behaviour (3).
>   *  an edit control not in a dialog without ES_MULTILINE and without
>  ES_WANTRETURN: behaviour (1).
>   *  an edit control not in a dialog with ES_MULTILINE and without
>  ES_WANTRETURN: behaviour (3).
>   *  an edit control not in a dialog with ES_MULTILINE and with
>  ES_WANTRETURN: behaviour (3).
>
>  This is how I interpret that part of the MSDN documentation. This
>  gives you the test cases needed to verify that your fix works in all
>  these possibilities. It also ensures that someone wanting to improve
>  the edit control does not regress this functionality, or breaks
>  something else in the process.

Edit controls get used in tons of applications, and its behavior can
be tricky to get right. Especially in the case of ES_MULTILINE without
ES_WANTRETURN. In the last two releases, I have managed to break the
edit control several times, and the thing that really helped me figure
out the proper fix is to write lots of test cases to cover as many
usage scenarios as possible.

Of course, writing tests is time consuming, and it's not always
possible to cover all the usage cases. With the native notepad bug,
it's because I didn't test the behavior when not inside a dialog box
well enough. I don't know if Reece's interpretation of MSDN is 100%
correct either, so the best thing to do is to write tests.

With regards to the patch, if EDIT_IsInsideDialog returns false, then
you don't want to send DM_GETDEFID either.