On Fri, Sep 21, 2018 at 4:57 PM, Alexandre Julliard julliard@winehq.org wrote:
Huw Davies huw@codeweavers.com writes:
On Fri, Sep 21, 2018 at 03:38:39PM +0300, Gabriel Ivăncescu wrote:
On Fri, Sep 21, 2018 at 3:02 PM, Huw Davies huw@codeweavers.com wrote:
As I hinted at above, unless you can type very much faster than me then I don't consider this much of an issue.
Well it's not much of an issue but it's still a slight improvement for the wineserver to have to process less in its queue, and all it needs is change a few lines (4 in total) from SendMessage to CallWindowProc.
Are you sure you don't want me to do that?
Yes.
It may only be 4 lines, but it's a reasonably fundamental change to how things work which will require time to review and add to the possibility of regressions. So if it's not actually improving things in a noticable manner then it should stay out.
Not to mention that SendMessage doesn't do a wineserver call for the thread-local case, so it's not even improving anything.
-- Alexandre Julliard julliard@winehq.org
Yeah but it's not the SendMessage that's the wineserver call I'm talking about, but the fact that it will go through this subclassed window procedure again (it starts at the top), which ends up calling GetPropW to get the This pointer just to forward it to the edit control. As I see, GetPropW uses a wineserver call.
In contrast, CallWindowProc on the This->wpOrigEditProc would obviously bypass this (which is what the original would end up doing anyway, since we don't handle WM_GETTEXT and such in our subclassed proc).