Page 1 of 1
wxGTK Accelerators
Posted: Fri Nov 08, 2019 4:16 pm
by heinermueller
Hi all,
i realized that the accelerators as we used to define them do not work under wxGTK3 and wx 3.0.4. It used to work (and works under win 2.8 and wxCocoa 3.x) like this:
Code: Select all
fileMenu->Append(wxID_HIGHEST + MENUOPEN, _("Open File\tCTRL+O"));
but now we have to add a call to SetAcceleratorTable:
Code: Select all
wxAcceleratorEntry entries[4];
entries[0].Set(wxACCEL_CTRL, (int) 'O', wxID_HIGHEST + MENUOPEN);
wxAcceleratorTable accel(1, entries);
frame->SetAcceleratorTable(accel);
This works fine (but the filemenu "Open File\tCTRL+O" entry is still needed to display the shortcut to the software user). Is this intended behaviour? If so, we can add the table - else this would be a duplication of definitions, which is likely to produce errors in the long run.
With the best regards
Re: wxGTK Accelerators
Posted: Fri Nov 08, 2019 5:03 pm
by ONEEYEMAN
Hi,
What is your OS?
What version of GTK+ do you use?
Can you try a {dialogs} sample and see if the accelerators in the menu work there?
Thank you.
Re: wxGTK Accelerators
Posted: Fri Nov 08, 2019 7:32 pm
by heinermueller
What is your OS?
What version of GTK+ do you use?
Can you try a {dialogs} sample and see if the accelerators in the menu work there?
OS is
System: Host: mxw-mint Kernel: 4.15.0-54-generic x86_64 bits: 64 compiler: gcc v: 7.4.0
Desktop: Cinnamon 4.2.4 wm: muffin dm: LightDM Distro: Linux Mint 19.2 Tina
base: Ubuntu 18.04 bionic gtk3
I checked out wxWidgets from git and checked out v3.0.4 tag (what wx-config returns). The accelerators work in the dialogs sample, but i do not see any difference in the code.
Re: wxGTK Accelerators
Posted: Fri Nov 08, 2019 8:24 pm
by doublemax
The "dialogs" sample doesn't use a dedicated wxAcceleratorTable. Try the "printing" sample and then try "CTRL-V" which should open a preview window.
Re: wxGTK Accelerators
Posted: Fri Nov 08, 2019 8:30 pm
by ONEEYEMAN
doublemax,
I think OP is complaining that on GTK he has to use accelerator table while MSW and OSX do not require it.
Thank you.
Re: wxGTK Accelerators
Posted: Mon Nov 11, 2019 10:03 am
by heinermueller
Code: Select all
I think OP is complaining that on GTK he has to use accelerator table while MSW and OSX do not require it.
Yes, we need an accelerator table to make shortcuts work. Our acceleration entries including the ones from the samples - when i copy them over to our code - do not work. Does anyone have any idea or debugging strategy where these shortcuts could get 'lost'? Is there a possibility to overwrite them all at once unintentionally?
Re: wxGTK Accelerators
Posted: Mon Nov 11, 2019 11:18 am
by DavidHart
Hi,
If the same accelerators, menu-entries etc as work in the samples, fail in your code, presumably the problem lies in how the events are handled.
First, I suggest you try F1 the 'minimal' sample as that's far simpler than 'dialogs'. If that works but the same accelerators fail in your code, look at where you try to catch those shortcuts. The samples do so in the frame. If you are trying to catch them elsewhere it's likely to be the reason. Another thing to try is a different Window Manager/Desktop Environment as some swallow some accelerators (though the 'minimal' F1 works in Cinnamon on Mint 19.1).
Edit: Actually, forget what I said about the DE: if the sample works OK, obviously that can't be the cause.
If neither is the reason, it's unlikely that we are going to be able to help without seeing at least some failing code...
Regards,
David
Re: wxGTK Accelerators
Posted: Mon Nov 11, 2019 5:40 pm
by heinermueller
Hi David,
thank you for the detailed answer! I checked for your suggestions and had a look inside the 'render' sample
- it uses accelerators
Code: Select all
menuFile->AppendCheckItem(Render_DrawDisabled, "Draw in &disabled state\tCtrl-D");
- it catches them in the frame
Code: Select all
wxBEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_MENU(Render_DrawDisabled, MyFrame::OnDrawDisabled)
....
wxEND_EVENT_TABLE()
- it works
So in our application,
- we use accelerators
Code: Select all
fileMenu->Append(wxID_HIGHEST + MENULOADALL, _("&Load\tCTRL+L"));
- we catch them in the frame
Code: Select all
BEGIN_EVENT_TABLE(mxwFrame, wxFrame)
....
EVT_MENU(wxID_HIGHEST+MENULOADALL, mxwFrame::OnLoadAll)
....
END_EVENT_TABLE()
- it does not work (in wxGTK)
I have the feeling the entries get overwritten/lost anything like that. Any idea how i could check that?
Is there a kind of event table 'getter' that i could call and check for changes?
Best,
Re: wxGTK Accelerators
Posted: Mon Nov 11, 2019 6:23 pm
by doublemax
Are both these code snippets in the same file?
How is MENULOADALL defined?
Is it possible that the _() macro messes the string up?
If all that doesn't help, you'll need to try to create a minimal sample that shows the issue.
Re: wxGTK Accelerators
Posted: Mon Nov 11, 2019 8:07 pm
by heinermueller
Hello doublemax,
- yes, (our) both snippets are in the same file
- MENULOADALL is defined like
Code: Select all
enum menuitems
{
MENURELOAD = 10
,MENUNEW
,MENUOPEN
,MENUSAVE
,MENUSAVEAS
,MENUSAVEALL
,MENUSAVEALLAS
,MENULOADALL
...
};
- i tried removing the translation macro _() and removed all other menu entries just to be sure,
but it makes no difference
Is there a ways to 'read' those acceleration entries back? So i could track down where they
have been altered
Re: wxGTK Accelerators
Posted: Mon Nov 11, 2019 9:33 pm
by doublemax
You can read the table back with wxWindow::GetAcceleratorTable. But i'm not even sure if the menu shortcuts end up in that table.
Re: wxGTK Accelerators
Posted: Wed Nov 13, 2019 2:01 pm
by heinermueller
I read back with
Code: Select all
wxMenuitem* m1 = fileMenu->Append(wxID_HIGHEST + MENUOPEN, _("Open File\tCTRL+O"));
auto a = m1->GetAccel();
and there is an accelerator set, and it stays that way trough the application lifetime. So it gets initialized, but is not active. Shall i report this as a bug?
Re: wxGTK Accelerators
Posted: Wed Nov 13, 2019 3:28 pm
by DavidHart
It would be interesting to override wxApp::FilterEvent and add some log code. You might find the event (presumably there
is one in this situation) is fired but doesn't reach the frame.
Shall i report this as a bug?
IMO only if you can create a reproducer; preferably as a patch to one of the wx samples.