Pressing F2 hides the log window but does not show it again while the editor-window is active. One has to click another Window first to be able to show the log window again (or use the menu).
Happens on Debian Jessie with Nightly build: Dec 10 2015, 22:09:58 - wx3.0.2(Linux, unicode) - 64 bit.
This also occurs with 13.12 (Linux) release. It does not occur on Windows.
Disabling keybinder plugin fixes it.
Will this item be solved?
I just found out after updating from the 2013 version.
Bit fo a downer that this item is know since end of 2015 and half 2016 no progress.
Just a workaround which I can not use as I need the ctrl+q for opening the folder containing the compiled program.
(running debian x64)
Last edit: Jeffrey Westgeest 2016-05-30
Someday it will be fixed, but first we need to find the reason why it happens.
I couldn't understand why it happens after a minimal debug session. :(
When I get annoyed by it again I'll try to fix it, but for now I have some higher priority issues I need to solve.
Feel free to debug it and post a patch. I'll happily review it.
I am really annoyed by this and i started debugging it. My findings so far:
returns false with wx3.0
can someone check if this is also the case on wx2.8? I think there is a change in behavior in wx3.0...
I am talking about the code in main.cpp:4448
I think the problem is, that OnViewMenuUpdateUI is not called properly and so the status of the menu item is not updated. The OnToggleBar function uses the menu item status as flag.
Possible solutions:
1) introduce a flag as member that represents the menu sate
2) Toggle the window: If it is shown hide it and vice versa not looking at the menu state
3) Look why wxWidgets 3.0 does not call OnViewMenuUpdateUI (it calls this function if you open the menu, but not other ways).
One possible fix: Toggle the window: If it is shown hide it and vice versa not looking at the menu state
We first need to find why the keybinder plugin causes this problem after that we can think about a solution. And we need to find why it is working in wx2.8.
This bug is Linux system only. I can't reproduce on Windows either wx2.8 or wx 3.1.
SVN 11342 should fix this problem.
All items in the View menu have been bypassed in KeyBinder by issuing an event.Skip(); return;.
I know this isn't optimal, but at least it eliminates the annoyance.
Any idea why it happens? Why after the change to wx3.x?
Yes, bluehazzards analysis led me right to the problem.
On both windows and gtk, programmatically setting a menu check item no longer works.
Once unchecked, it cannot be re-checked even with ProcessEvent() or AddPendingEvent.
Nor does calling menu->UpdateUI()
Here's a statement from the docs:
"On Windows and GTK+, events for menubar items are only sent when the menu is about to be shown, and not in idle time".
I read that as meaning the check status on menu items will only be updated when the menu is manually selected/shown.
It's not a large loss. It just means that secondary hotkeys will no longer work for check menu items.
If a user attempts to add a seconday hotkey, I'll have to find a way to inform the user that it's not possible.
Fixed SVN 11342
I'm still seeing this problem. :(
Running r11365, wxGTK 3.0.3, gentoo linux...
This is fixed how? I am still not able to open the Log using a key.
R11810 wx 3.0.4 on Linux Mint 19.1 Mate
I guess, it isn't there is new implementation of the keybinder plugin and it broke it again.
@pecanh Could you look at it?
Fixed (again) rev 11825
main.cpp - OnToggleBar: For checked menu items, event.IsChecked() may not reflect the current status of the menu item when the event was previously event.Skip()'ed after the menu item was change.
The skipped event reflects the stale value of the menu item.
We have to actually look at the menu item with wxMenu->IsChecked(menuId) or use LayoutManager.GetPane(win).IsShown(). IsShown() is reliable.
In my testing it works okay on Linux Mint 20.1 with CB SVN12286 wxWidget 3.0.4.
With the posts above indicating it has been fixed and my testing then IMHO this ticket can be closed and if someone finds it has not then it could be re-opned or a new ticket created.
Yeah, thanks. Also seems to work on my current debian system.