On Thu, 23 Jan 2020 15:44:44 +0300 Nikolay Sivov bunglehead@gmail.com wrote:
NS> > On 23/01/2020 09:11, Alistair Leslie-Hughes wrote: NS> > > Hi Vadim, [...] NS> > > When I developed this patch, I didn't know about Ctrl-Ins acting the NS> > > same as Ctrl-C.
Hi Alistair and Nikolay,
I'm particularly partial to using Ctrl-Ins as I'm too used to using it myself and my motivation for writing this patch was to improve Wine for my personal use, so I'd really like to see this key combination supported too. Of course, it's trivial to update your patch to do it by reusing the condition from mine i.e.:
+ if ((msg.message == WM_CHAR && + LOBYTE(msg.wParam) == 3) || + (msg.message == WM_KEYDOWN && + LOBYTE(msg.wParam) == VK_INSERT && + GetKeyState(VK_CONTROL) < 0))
But unfortunately I have no idea about how to update the tests to pass for any locale...
And I still don't know whether we should be using a hook here, which is IMHO is also an important question.
NS> Both hook and changing general dialog code just for that is not great.
I definitely agree with this, but unfortunately I couldn't find any better way and I don't think it's possible to do it purely locally, i.e. only at the level of message box itself, because pressing Ctrl-C (or Ins) is supposed to work even when the focus is not on the message box (because it never is). I guess we could subclass all the message box children to propagate this message upwards, but this doesn't seem to be really appealing neither.
NS> Is there really no way to intercept this?
Not at message box level, AFAICS. FWIW native MSW itself seems to do something similar to my patch.
NS> Does actual window procedure still receive WM_KEY*?
Which one? The message box doesn't, and never did. The child window does receive it, the same as before. In my patch this happens because I intentionally don't stop processing after doing SendMessage(WM_COPY), even if it's handled. Again, this is done in order to be consistent with the native behaviour.
Regards, VZ