On Sat, Apr 19, 2008 at 4:05 AM, Reece Dunn msclrhd@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:
- the default push button is not activated; the edit contents is unchanged.
- the default push button is activated; the edit contents is unchanged.
- 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.