On Thu, Jan 23, 2020 at 3:30 PM Gabriel Ivăncescu <gabrielopcode@gmail.com> wrote:
On 23/01/2020 09:11, Alistair Leslie-Hughes wrote:
> Hi Vadim,
>
> On 23/1/20 10:40 am, Vadim Zeitlin wrote:
>>    Looking at this patch, I see that it's clearly better than mine in some
>> aspects (e.g. it includes tests) but OTOH I'm not sure if using a hook for
>> this is really a good idea, and it seems to have resulted in the problems
>> as discussed at the bug above. There is also another small but annoying
>> difference: the other patch doesn't take Ctrl-Ins into account, even though
>> it works in the same way as Ctrl-C under native MSW.
> When I developed this patch, I didn't know about Ctrl-Ins acting the
> same as Ctrl-C.
>
>>
>>    So what should/can I do now? Would it be worth to update my patch to
>> combine it with the tests from the patch by Alistair Leslie-Hughes? Also,
>> mostly for the future, should I have submitted this patch to Wine staging
>> instead of here?
> The only issue I know about getting these patches upstream is the tests.
>    They need to be updated so they will work on any locale not just English.
>
> If you want to write the patch to allow "Ctrl-Ins", that extends the
> current patchset, I can put it in staging for you.  Then all that would
> be required is a new set of tests.
>
> Regards
> Alistair.
>

Also FWIW, I haven't found any problems with the staging patch for a
long time ever since it has been updated to use a thread local hook
instead of global, so that's not an issue.

Both hook and changing general dialog code just for that is not great. Is there really no way to intercept this? Does actual window procedure still receive WM_KEY*?