On Wed, Sep 12, 2018 at 1:52 PM, Huw Davies huw@codeweavers.com wrote:
I don't follow. All of the uses of hwndText are inside the current WM_KEYUP handler (at least after you resend the dynamic allocation of hwndText patch), so what's the issue?
Remember, you're trying to make this as simple as possible for the reviewers. If there is a straight copy-n-paste patch into a helper that makes life easy. If not, then it's a large patch to review.
Huw.
Well, with WM_KEYDOWN the hwndText allocation has to be done inside WM_CHAR and only in VK_RETURN part of WM_KEYDOWN.
The reason it has to be done in WM_CHAR is because we have to first pass the WM_CHAR message through to the edit control and *then* get the resulting text. And we can't just pass through the message before WM_CHAR, because VK_RETURN and the arrow keys have to eat it and not forward it for proper behavior (for example arrow keys can conflict with a combo box's arrow keys otherwise, tested this in Total Commander, this doesn't happen on Windows; the return key needs more fixes to match Windows but that will come later).
That said, I'll split it then, cause it seems a bit big indeed.
I hope you don't mind I'll do some basic syntactic changes in the first patch instead of a straight cut & paste (trivial stuff like braces on new lines, changing names from hwndText to just text, and This to ac, and so on, no actual changes to the code behavior).