[Windows 10 wxWidgets 3.0] Event.Skip() not always respected

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Windows 10 wxWidgets 3.0] Event.Skip() not always respected

peter.koch.larsen
Dear group,

I have a problem with an annoying "bell" sound when I use keyboard shortcuts in my application. I have written about it in the wxwidgets forum, which you can see here: https://forums.wxwidgets.org/viewtopic.php?f=1&t=44704&p=185026#p185026.
There you can also find source-code to demonstrate the problem.

Basically, I have a textctrl which wants to capture Alt-G. It binds to this function:

    void on_key_down(wxKeyEvent& kd_info)
    {
        if (kd_info.GetModifiers() == wxMOD_ALT && kd_info.GetKeyCode() == 'G')
        {
            kd_info.Skip(false);
            this->SetValue("HELLO");
        }
    }


Now, if I place this textctrl in a wxFrame, everything works fine. But if I place it in a wxDialog, I receive a "Bell" sound indicating that the event is not handled. I have found that the culprit might be this code (windows.cpp line 3206).

   if (message == WM_SYSKEYDOWN)  // Let Windows still handle the SYSKEYs
      processed = false;


The Alt-D combination is regarded as a SYSKEY when in a dialog.
Any idea how to get around this? And why, oh why, does wxWidgets not respect that I mean it when I instruct it to skip an event?


/Peter



--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: [Windows 10 wxWidgets 3.0] Event.Skip() not always respected

Vadim Zeitlin-4
On Sun, 17 Jun 2018 01:18:52 -0700 (PDT)  wrote:

> Now, if I place this textctrl in a wxFrame, everything works fine. But if I
> place it in a wxDialog, I receive a "Bell" sound indicating that the event
> is not handled. I have found that the culprit might be this code
> (windows.cpp line 3206).
>
>    if (message == WM_SYSKEYDOWN)  // Let Windows still handle the SYSKEYs
>       processed = false;
>
> The Alt-D combination is regarded as a SYSKEY when in a dialog.

 Just to be clear, it's always regarded as a SYSKEY, but only DefDlgProc
(and not DefWndProc) calls MessageBeep() when it gets an unrecognized
SYSKEY.

> Any idea how to get around this? And why, oh why, does wxWidgets not
> respect that I mean it when I instruct it to skip an event?

 Good question... This was added 15+ years ago in

https://github.com/wxWidgets/wxWidgets/commit/e771b7e4ac5c7f73a579f7329ce15e2d6710670d?w=1

but I don't find the explanation very convincing: arguably, it should be
possible to prevent Alt-Space from opening the system menu if you really
don't want it to do it for some reason by handling (and not skipping) it.
So I think we should revert this and will do it if there are no objections
(cc'ing Robin just to make sure he sees it and has a chance to object).

 Of course, such change can't be done in 3.0 branch as it can silently
change the application behaviour, so this will only be included in 3.2. In
the meanwhile, you could backport the upcoming commit to your own private
branch or use some workaround, e.g. override MSWHandleMessage() to return
true for this particular message.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Windows 10 wxWidgets 3.0] Event.Skip() not always respected

peter.koch.larsen
Thank you for your insightful answer.

søndag den 17. juni 2018 kl. 17.48.16 UTC+2 skrev Vadim Zeitlin:
On Sun, 17 Jun 2018 01:18:52 -0700 (PDT)  wrote:

> Now, if I place this textctrl in a wxFrame, everything works fine. But if I
> place it in a wxDialog, I receive a "Bell" sound indicating that the event
> is not handled. I have found that the culprit might be this code
> (windows.cpp line 3206).
>
>    if (message == WM_SYSKEYDOWN)  // Let Windows still handle the SYSKEYs
>       processed = false;
>
> The Alt-D combination is regarded as a SYSKEY when in a dialog.

 Just to be clear, it's always regarded as a SYSKEY, but only DefDlgProc
(and not DefWndProc) calls MessageBeep() when it gets an unrecognized
SYSKEY.

Okay. I am a novice when it comes to user-interfaces.
 

> Any idea how to get around this? And why, oh why, does wxWidgets not
> respect that I mean it when I instruct it to skip an event?

 Good question... This was added 15+ years ago in

<a onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FwxWidgets%2FwxWidgets%2Fcommit%2Fe771b7e4ac5c7f73a579f7329ce15e2d6710670d%3Fw%3D1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXVu256xfvWnLs3r8LDl0CjcUIwQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FwxWidgets%2FwxWidgets%2Fcommit%2Fe771b7e4ac5c7f73a579f7329ce15e2d6710670d%3Fw%3D1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXVu256xfvWnLs3r8LDl0CjcUIwQ&#39;;return true;" href="https://github.com/wxWidgets/wxWidgets/commit/e771b7e4ac5c7f73a579f7329ce15e2d6710670d?w=1" target="_blank" rel="nofollow">https://github.com/wxWidgets/wxWidgets/commit/e771b7e4ac5c7f73a579f7329ce15e2d6710670d?w=1

but I don't find the explanation very convincing: arguably, it should be
possible to prevent Alt-Space from opening the system menu if you really
don't want it to do it for some reason by handling (and not skipping) it.
So I think we should revert this and will do it if there are no objections
(cc'ing Robin just to make sure he sees it and has a chance to object).

I could not agree more.  If the user wants to stop an event to propagate, the event should not propagate. This is simply a question about having a consistent user-interface. You won't have that if you second-guess the wishes of the user and overrides his actions.


 Of course, such change can't be done in 3.0 branch as it can silently
change the application behaviour, so this will only be included in 3.2. In
the meanwhile, you could backport the upcoming commit to your own private
branch or use some workaround, e.g. override MSWHandleMessage() to return
true for this particular message.

An alternative solution would be have a new member-function AlwaysSkip which should probably not have any parameters.
You could keep binary compatibility  by having it inline, and changing the bool member to an uint8_t or unsigned char, stored in an union to assure the same size as a byte. It is a kludge, of course.

I did a quick-and dirty edit and removed the offensive line. I  still get the Beep, though. Will investigate and try to find out why I get that annoying beep.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               <a onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.tt-solutions.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFhPHTZbdYZYM-AqcnZXykG1ueWhw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.tt-solutions.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFhPHTZbdYZYM-AqcnZXykG1ueWhw&#39;;return true;" href="http://www.tt-solutions.com/" target="_blank" rel="nofollow">http://www.tt-solutions.com/

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[2]: [Windows 10 wxWidgets 3.0] Event.Skip() not always respected

Vadim Zeitlin-4
On Sun, 17 Jun 2018 12:57:40 -0700 (PDT) Peter Koch Larsen wrote:

> søndag den 17. juni 2018 kl. 17.48.16 UTC+2 skrev Vadim Zeitlin:
> >
> > On Sun, 17 Jun 2018 01:18:52 -0700 (PDT)  wrote:
[...]

> > > Any idea how to get around this? And why, oh why, does wxWidgets not
> > > respect that I mean it when I instruct it to skip an event?
> >
> >  Good question... This was added 15+ years ago in
> >
> > https://github.com/wxWidgets/wxWidgets/commit/e771b7e4ac5c7f73a579f7329ce15e2d6710670d?w=1 
> >
> > but I don't find the explanation very convincing: arguably, it should be
> > possible to prevent Alt-Space from opening the system menu if you really
> > don't want it to do it for some reason by handling (and not skipping) it.
> > So I think we should revert this and will do it if there are no objections
> > (cc'ing Robin just to make sure he sees it and has a chance to object).
>
> I could not agree more.  If the user wants to stop an event to propagate,
> the event should not propagate. This is simply a question about having a
> consistent user-interface. You won't have that if you second-guess the
> wishes of the user and overrides his actions.
 Just FYI, I've finally done this change now in

https://github.com/wxWidgets/wxWidgets/commit/d1175c00e19350df4db655c226ada91eada3e7a4


> >  Of course, such change can't be done in 3.0 branch as it can silently
> > change the application behaviour, so this will only be included in 3.2. In
> > the meanwhile, you could backport the upcoming commit to your own private
> > branch or use some workaround, e.g. override MSWHandleMessage() to return
> > true for this particular message.
>
> An alternative solution would be have a new member-function AlwaysSkip
> which should probably not have any parameters.

 No, sorry, I don't think it's worth it. Skip() semantics is already
confusing enough without adding AlwaysSkip().

> You could keep binary compatibility  by having it inline, and changing the
> bool member to an uint8_t or unsigned char, stored in an union to assure
> the same size as a byte. It is a kludge, of course.

 Yes, and I'm not ready to do something as horrible as this for just this
relatively minor problem.

> I did a quick-and dirty edit and removed the offensive line. I  still get
> the Beep, though. Will investigate and try to find out why I get that
> annoying beep.

 You should be able to put a breakpoint on MessageBeep (depending on the
debugger you use, you may or not have to use the decorated name) to see
where exactly is it called from.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Windows 10 wxWidgets 3.0] Event.Skip() not always respected

Robin Dunn
In reply to this post by Vadim Zeitlin-4
On Sunday, June 17, 2018 at 8:48:16 AM UTC-7, Vadim Zeitlin wrote:
On Sun, 17 Jun 2018 01:18:52 -0700 (PDT)  wrote:

> Now, if I place this textctrl in a wxFrame, everything works fine. But if I
> place it in a wxDialog, I receive a "Bell" sound indicating that the event
> is not handled. I have found that the culprit might be this code
> (windows.cpp line 3206).
>
>    if (message == WM_SYSKEYDOWN)  // Let Windows still handle the SYSKEYs
>       processed = false;
>
> The Alt-D combination is regarded as a SYSKEY when in a dialog.

 Just to be clear, it's always regarded as a SYSKEY, but only DefDlgProc
(and not DefWndProc) calls MessageBeep() when it gets an unrecognized
SYSKEY.

> Any idea how to get around this? And why, oh why, does wxWidgets not
> respect that I mean it when I instruct it to skip an event?

 Good question... This was added 15+ years ago in

<a href="https://github.com/wxWidgets/wxWidgets/commit/e771b7e4ac5c7f73a579f7329ce15e2d6710670d?w=1" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FwxWidgets%2FwxWidgets%2Fcommit%2Fe771b7e4ac5c7f73a579f7329ce15e2d6710670d%3Fw%3D1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXVu256xfvWnLs3r8LDl0CjcUIwQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FwxWidgets%2FwxWidgets%2Fcommit%2Fe771b7e4ac5c7f73a579f7329ce15e2d6710670d%3Fw%3D1\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXVu256xfvWnLs3r8LDl0CjcUIwQ&#39;;return true;">https://github.com/wxWidgets/wxWidgets/commit/e771b7e4ac5c7f73a579f7329ce15e2d6710670d?w=1

but I don't find the explanation very convincing: arguably, it should be
possible to prevent Alt-Space from opening the system menu if you really
don't want it to do it for some reason by handling (and not skipping) it.
So I think we should revert this and will do it if there are no objections
(cc'ing Robin just to make sure he sees it and has a chance to object).


A little late, but no objections from me.

--
Robin
 

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[2]: [Windows 10 wxWidgets 3.0] Event.Skip() not always respected

Vadim Zeitlin-4
On Tue, 26 Jun 2018 17:26:52 -0700 (PDT) Robin Dunn wrote:

RD> On Sunday, June 17, 2018 at 8:48:16 AM UTC-7, Vadim Zeitlin wrote:
RD> >
RD> > On Sun, 17 Jun 2018 01:18:52 -0700 (PDT)  wrote:
RD> >
RD> > > Now, if I place this textctrl in a wxFrame, everything works fine. But
RD> > if I
RD> > > place it in a wxDialog, I receive a "Bell" sound indicating that the
RD> > event
RD> > > is not handled. I have found that the culprit might be this code
RD> > > (windows.cpp line 3206).
RD> > >
RD> > >    if (message == WM_SYSKEYDOWN)  // Let Windows still handle the
RD> > SYSKEYs
RD> > >       processed = false;
RD> > >
RD> > > The Alt-D combination is regarded as a SYSKEY when in a dialog.
RD> >
RD> >  Just to be clear, it's always regarded as a SYSKEY, but only DefDlgProc
RD> > (and not DefWndProc) calls MessageBeep() when it gets an unrecognized
RD> > SYSKEY.
RD> >
RD> > > Any idea how to get around this? And why, oh why, does wxWidgets not
RD> > > respect that I mean it when I instruct it to skip an event?
RD> >
RD> >  Good question... This was added 15+ years ago in
RD> >
RD> >
RD> > https://github.com/wxWidgets/wxWidgets/commit/e771b7e4ac5c7f73a579f7329ce15e2d6710670d?w=1 
RD> >
RD> > but I don't find the explanation very convincing: arguably, it should be
RD> > possible to prevent Alt-Space from opening the system menu if you really
RD> > don't want it to do it for some reason by handling (and not skipping) it.
RD> > So I think we should revert this and will do it if there are no objections
RD> > (cc'ing Robin just to make sure he sees it and has a chance to object).
RD>
RD> A little late, but no objections from me.

 Thanks! Just FYI, I did this in d1175c00e19350df4db655c226ada91eada3e7a4,
so if you now get complaints about syskeys not working any more, you know
whom to blame.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment