Hi,
Sent to wine-devel as well: this might break some odd edit controls that I did not catch.
This fixes masked edit controls used by applications created by Power Builder, it fixes bug #807. Power builder depends on the return value of the WM_CREATE message by the EditWndProc to be != 0.
Now I spent some time creating EDIT windows, varying parameters (with or without text), varying styles including multilines even tested the edit part of a combobox. In all cases the WM_CREATE message return value turned out to be 1. So at the very least this seems to be the common case, and not zero as in wine's implementation. So I propose to put that in, and if it breaks hope it will be caught.
ChangeLog: controls : edit.c A WM_CREATE message sent to an Edit window procedure should return 1. Power Builder masked edit controls depend on it.
Rein.
On October 19, 2003 11:10 am, Rein Klazes wrote:
Now I spent some time creating EDIT windows, varying parameters (with or without text), varying styles including multilines even tested the edit part of a combobox. In all cases the WM_CREATE message return value turned out to be 1. So at the very least this seems to be the common case, and not zero as in wine's implementation.
A conformance test would be nice, as this is far from obvious...
On Sun, 19 Oct 2003 12:19:10 -0400, you wrote:
On October 19, 2003 11:10 am, Rein Klazes wrote:
Now I spent some time creating EDIT windows, varying parameters (with or without text), varying styles including multilines even tested the edit part of a combobox. In all cases the WM_CREATE message return value turned out to be 1. So at the very least this seems to be the common case, and not zero as in wine's implementation.
A conformance test would be nice, as this is far from obvious...
Sorry, but what is not obvious about this:
| /* The rule seems to return 1 here for success */ | /* Power Builder masked edit controls will crash */ | /* if not. */ | /* FIXME: is that in all cases so ? */ | return 1;
(And that is before the spelling squad had a chance to correct the mistakes in my English.)
I cannot imagine the conformance here to be accidentally "lost". I am not against conformance tests in general, but to protect such simple one-line functionality seems to me a waste of the effort.
Rein.
On October 20, 2003 02:55 am, Rein Klazes wrote:
I cannot imagine the conformance here to be accidentally "lost". I am not against conformance tests in general, but to protect such simple one-line functionality seems to me a waste of the effort.
Right, but the test would also tell us if all Windows versions behaved similarly... In other words, executable code is a lot more useful than a comment. To put it another way, I think the comment belongs with the test :)
On Tue, 21 Oct 2003 00:12:20 -0400, you wrote:
On October 20, 2003 02:55 am, Rein Klazes wrote:
I cannot imagine the conformance here to be accidentally "lost". I am not against conformance tests in general, but to protect such simple one-line functionality seems to me a waste of the effort.
Right, but the test would also tell us if all Windows versions behaved similarly...
See? You are looking for an if-else-statement yourself. Perhaps there is not one. And if there is, it may test numerous other things then the Windows version.
Anyway I have already verified this under win98, win2k and for win16 code (tested that under win2k). Each and every edit control that I threw at it returned 1 at the wm_create message.
If you are not satisfied try it yourself: fire up spy++ under some winXX version; select all windows in the system; deselect all messages except WM_CREATE; do some things that create windows; study the spy's output. Until now all messages that I have seen that return 1 are edit/combo controls, and the rest are not.
In other words, executable code is a lot more useful than a comment.
I am not convinced of that and it is not the point: the time to create/test/excute the test could be used far more better spent (like tests for things that are known for sure to be non-obvious or complex).
To put it another way, I think the comment belongs with the test :)
I rather have that comments come with the code.
Rein.
On October 21, 2003 09:00 am, Rein Klazes wrote:
See? You are looking for an if-else-statement yourself. Perhaps there is not one. And if there is, it may test numerous other things then the Windows version.
I am not. But knowing is various Windows versions are consistent in certain behavior tells us how important that particular thing is.
Anyway I have already verified this under win98, win2k and for win16 code (tested that under win2k). Each and every edit control that I threw at it returned 1 at the wm_create message.
I believe you, it's just that all your experience went into a comment, which is non-executable. This is more a philosophical issue, but to me executable code is _always_ better than words. With the new testing infrastructure we put in place, we'll have these tests run regularly on all windows versions, past, present and future.
The problem with comments only is that they may not be convincing in a few years. A *recently* run test (as we hope to have fresh results for all Wine releases) is a lot more convincing. Also, adding a lot of information in your comments is also not good, it uglifies and clutter the code. Not adding it wastes all the info you've learn the hard way.
Putting a terse comment in the code, and the rest in the test solves this dilemma beautifully: code is clean, information is not lost, and something constantly checks that it is still current/relevant. Yes, it costs you a bit more initially to write the test, but it pays out rather quickly.
Now, if you don't want to do it, fine, I don't mean to force you. But I think it would be good policy to supply patches that fix such bugs with accompanying tests. It would be a way to codify into live, working code the experience you've gathered the hard way.
-
Dimitrie O. Paun -
Rein Klazes