"Lei Zhang" thestig@google.com wrote:
This patch lets users hit ctrl + Z in edit controls to trigger an undo. The test case has been improved to check for both the return values and the content of the edit control.
In the tests still there is no actual edit contents/selection changes tracking after every message.
On 9/10/07, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"Lei Zhang" thestig@google.com wrote:
This patch lets users hit ctrl + Z in edit controls to trigger an undo. The test case has been improved to check for both the return values and the content of the edit control.
In the tests still there is no actual edit contents/selection changes tracking after every message.
-- Dmitry.
I'm sending WM_GETTEXT to the control and then checking the text after every change. Did you mean something else when you say contents changes tracking?
"Lei Zhang" thestig@google.com wrote:
In the tests still there is no actual edit contents/selection changes tracking after every message.
-- Dmitry.
I'm sending WM_GETTEXT to the control and then checking the text after every change. Did you mean something else when you say contents changes tracking?
I mean that after every message you send you need to send WM_GETTEXT and EM_GETSEL messages to the control and check what they return, that's what I call actual edit contents/selection changes tracking. By "what they return" I also mean for WM_GETTEXT not only SendMessage return value but also the contents of the buffer.
On 9/10/07, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"Lei Zhang" thestig@google.com wrote:
In the tests still there is no actual edit contents/selection changes tracking after every message.
-- Dmitry.
I'm sending WM_GETTEXT to the control and then checking the text after every change. Did you mean something else when you say contents changes tracking?
I mean that after every message you send you need to send WM_GETTEXT and EM_GETSEL messages to the control and check what they return, that's what I call actual edit contents/selection changes tracking. By "what they return" I also mean for WM_GETTEXT not only SendMessage return value but also the contents of the buffer.
-- Dmitry.
Yes, I am already checking the return value and the contents of the buffer:
+ r = SendMessage(hwEdit, WM_GETTEXT, 1024, (LPARAM) buffer); + ok(r == strlen(text), "Expected: %d, got len %d\n", strlen(text), r); + ok(strcmp(buffer, text) == 0, "expected %s, got %s\n", text, buffer);
I'll add EM_GETSEL checks as well.
"Lei Zhang" thestig@google.com wrote:
I'll add EM_GETSEL checks as well.
I'm sorry, but in your latest patch you have added only one EM_GETSEL, but that's not "after every message" as repeated in each my mail.
On 9/11/07, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"Lei Zhang" thestig@google.com wrote:
I'll add EM_GETSEL checks as well.
I'm sorry, but in your latest patch you have added only one EM_GETSEL, but that's not "after every message" as repeated in each my mail.
-- Dmitry.
I feel "after every message" is bloating the test too much. If we take the approach where we believe anything can go wrong and check everything after every message, then we'll spend the rest of our lives writing tests.
The goal of this test is to make sure undo works. I had forgotten that hitting undo after a cut restores the previous selection. So yes, the test is not thorough enough. I will check the selection and check the buffer contents at the beginning and after every undo to make sure the pre and post conditions hold. Does this seem reasonable?
The goal here is not to verify setting test/cutting/pasting/selecting works. Those should be tested separately.
"Lei Zhang" thestig@google.com wrote:
I feel "after every message" is bloating the test too much. If we take the approach where we believe anything can go wrong and check everything after every message, then we'll spend the rest of our lives writing tests.
That's certainly an exaggeration. You've already spent more time resending a not complete patch, and arguing about it.
-
Dmitry Timoshkov -
Lei Zhang