wxAcceleratorEntry vs wxUpdateUIEvent

[wsu]

Is it expected that, even though the command referenced by an wxAccerlatorEntry is disabled in the corresponding menu item by wxUpdateUIEvent, the command will still be invoked by the accelerator key?

[Vadim Zeitlin]

On Tue, 5 May 2026 18:39:24 -0700 (PDT) 'wsu' via wx-dev wrote:

w> Is it expected that, even though the command referenced by an
w> wxAccerlatorEntry is disabled in the corresponding menu item
w> by wxUpdateUIEvent, the command will still be invoked by the accelerator
w> key?

Probably not. I guess we need to generate wxUpdateUIEvent before
dispatching the accelerator and skip doing it if the event handler
indicates that the object is disabled.

Regards,
VZ

[wsu]

I am looking at wxMSW wxFrame::MSWDoTranslateMessage() and wxAcceleratorTable::Translate(), and it doesn't look like there is any way to determine which command is about to be sent, and therefore no way to generate the appropriate wxUpdateUIEvent.  On the other hand, wxWindowMSW::HandleCommand() knows what command to test with wxUpdateUIEvent, but I don't see a how to check whether the command came from a menu or from an accelerator key.

By an interesting coincidence, for separate reasons I had already been wishing that wxCommandEvent was tagged with whether it was generated by a menu or an accelerator key.

[Vadim Zeitlin]

On Tue, 5 May 2026 21:48:07 -0700 (PDT) 'wsu' via wx-dev wrote:

w> I am looking at wxMSW wxFrame::MSWDoTranslateMessage()
w> and wxAcceleratorTable::Translate(), and it doesn't look like there is any
w> way to determine which command is about to be sent, and therefore no way to
w> generate the appropriate wxUpdateUIEvent.

Well, we have the ID and we probably could find the object that will be
handling it, but there is a simpler solution...

w> On the other hand, wxWindowMSW::HandleCommand() knows what command to
w> test with wxUpdateUIEvent, but I don't see a how to check whether the
w> command came from a menu or from an accelerator key.

Win32 provides this information to WM_COMMAND handler: the high word of
wParam is 0 for menu events and 1 for accelerators. There is a potential
ambiguity for WM_COMMAND sent for a control with ID=1, but I think nothing
really bad would happen if we sent an unwanted wxUpdateUIEvent in the
latter case, so we could simply always send it if HIWORD(wParam) != 0.

Regards,
VZ

[wsu]

On Wednesday, May 6, 2026 at 8:56:07 AM UTC-4 Vadim Zeitlin wrote:

Win32 provides this information to WM_COMMAND handler: the high word of
wParam is 0 for menu events and 1 for accelerators. There is a potential
ambiguity for WM_COMMAND sent for a control with ID=1, but I think nothing
really bad would happen if we sent an unwanted wxUpdateUIEvent in the
latter case, so we could simply always send it if HIWORD(wParam) != 0.

Now that you point this WM_COMMAND feature out, I see that wxMSW wxFrame::HandleCommand()'s comments already mention it.  With this information, I can probably implement wxUpdateUIEvent checking for wxAcceleratorEntry for wxMSW.  However, I can't implement this for any other port.  Would you like me to submit a PR that only supports wxMSW, or would you rather keep the ports consistent in their (unexpected) behavior until someone can fix this across ports?

[Vadim Zeitlin]

On Wed, 6 May 2026 18:22:22 -0700 (PDT) 'wsu' via wx-dev wrote:

w> Now that you point this WM_COMMAND feature out, I see that wxMSW
w> wxFrame::HandleCommand()'s comments already mention it. With this
w> information, I can probably implement wxUpdateUIEvent checking for
w> wxAcceleratorEntry for wxMSW. However, I can't implement this for any
w> other port.

I am not sure about wxOSX, but GTK doesn't map accelerators to menu
commands, so we should be able to implement this easily for wxGTK by just
setting the field differently in different places where the event is
generated.

w> Would you like me to submit a PR that only supports wxMSW,

Even if it would be preferable to implement this for at least one other
port, I think it's also fine to do this only for wxMSW to begin with.
However the "event source" field should then have value meaning "unknown"
and not just "menu" and "accelerator" so that the other ports could at
least avoid lying to the user.

Thanks,
VZ

[wsu]

On Saturday, May 9, 2026 at 3:46:29 PM UTC-4 Vadim Zeitlin wrote:

I am not sure about wxOSX, but GTK doesn't map accelerators to menu
commands, so we should be able to implement this easily for wxGTK by just
setting the field differently in different places where the event is
generated.

w> Would you like me to submit a PR that only supports wxMSW,

Even if it would be preferable to implement this for at least one other
port, I think it's also fine to do this only for wxMSW to begin with.
However the "event source" field should then have value meaning "unknown"
and not just "menu" and "accelerator" so that the other ports could at
least avoid lying to the user.

Wait,  maybe we're talking about different things here.  Are you talking about a PR that adds an "event source" field to the wxCommandEvent public API?  I did mention earlier that I wished that information was available to client code, but the PR I proposed here only uses the "event source" (provided by Windows) internally in the wxMSW implementation of wxWidgets.  (This would allow the wxMSW internal code to avoid repeating wxUpdateUIEvent checks for menu items while adding them for accelerator keys.)  However, if you support adding an "event source" field to the wxCommandEvent public API, I would be happy to use that approach.

[Vadim Zeitlin]

On Sat, 9 May 2026 22:06:33 -0700 (PDT) 'wsu' via wx-dev wrote:

w> Wait, maybe we're talking about different things here. Are you talking
w> about a PR that adds an "event source" field to the wxCommandEvent public
w> API?

Yes, I thought that was what you wanted to do.

w> I did mention earlier that I wished that information was available to
w> client code, but the PR I proposed here only uses the "event source"
w> (provided by Windows) internally in the wxMSW implementation of wxWidgets.

But I have no problem with doing just this either.

w> (This would allow the wxMSW internal code to avoid repeating
w> wxUpdateUIEvent checks for menu items while adding them for accelerator
w> keys.) However, if you support adding an "event source" field to the
w> wxCommandEvent public API, I would be happy to use that approach.

Please choose whatever you prefer.

Thanks,
VZ

[Ian McInerney]

Just a note that there was some previous discussion about an event source field for the command events in this thread: https://groups.google.com/g/wx-dev/c/Af_DkhANV_g/m/dV4qERooEAAJ.

I never got around to actually implementing it though.

-Ian