View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000857||OpenMPT||[All Projects] General||public||2016-08-08 17:45||2016-10-01 08:41|
|Reporter||Rapture||Assigned To||Saga Musix|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Product Version||OpenMPT 1.26.04.00 / libopenmpt 0.2-beta20 (upgrade first)|
|Target Version||OpenMPT 1.26.05.00 / libopenmpt 0.2-beta20.1 (upgrade first)||Fixed in Version||OpenMPT 1.26.05.00 / libopenmpt 0.2-beta20.1 (upgrade first)|
|Summary||0000857: More than one desired window get opened with certain key shortcuts|
For example, assigning "File/Export as lossless (Wave, FLAC)" to the key "U". When pressing U now 10 times, it opens the export dialogue 10 times on top of each other and you have to close 10 windows. This is not possible with clicking "File > Export as lossless (Wave, FLAC) with the mouse manually, as the file menu in the background is blocked when a window pops up (standard windows behaviour). With a shortcut to it, you can go around this "limitation" and open the dialogue as often as you want, which is undesirable.
Is that a thing that could be improved? I.e. no matter how many times you press the key "U" now, only and exactly one export dialogue will pop up and no more export windows can be created. Thanks!
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
Additional Info: You can create 14 windows max. ;) Why exactly 14, and if more/less/same on other dialogues than the export/wav/flac dialogue I don't know. ;)
The root cause here is the same as issue 0000713, namely the global keyboard hook that works in parallel to the window hierarchy and practically ignores it.
Thanks for your reply. Can you please explain it again, so that a non-coder like me can understand it? :) What does "hotkey handling" mean, let alone pretranslatemessage()?
Why is that shortcut useless? No shortcut is useless if the user wants it. For one guy it's useless but for another one maybe not. ;) If the user wants the export dialogue with "U" (I don't want it myself, I just played around in OpenMPT!), then it's the users decision. Can't call that useless, really. Maybe that multiple-window-popup-thingy is typical Microsoft Windows behaviour, but I don't see that so often or at all in other programs.
My whole comment was meant as a development analysis and remainder for us developers about how to solve this properly, so that we do not forget it.
Same thing here. I meant that it is implemented the wrong way internally, not that keyboard shortcuts are anywhere near useless in general.
Your bug report is totally valid. I did not mean to question that ;-).
Sorry for the confusion caused.
For the time being, we can disable the keyboard handler while the dialog is open, as it is already done with various other dialogs where it's not desired.
@manx, hehe, no problem, and no harm done. :)
By the way @manx, I don't think that issue 0000713 is necessarily the culprit here. The fact that certain keyboard shortcuts work in all contexts is certainly intentional, but for some other shortcuts it is of course... less practical that this happens. For example, it can be handy to have play/stop/etc. available also while a child window is focused. Maybe we need to specially flag shortcuts which should only be usable when the main window is focussed instead of adding workarounds each and every dialog that has such a shortcut.
Issue 0000713 is certainly related, as we are recursively entering the Keyboard Hook here. And that should never happen, ever, because it can totally confuse all state handling logic (this is not directly applicable to this issue, but think about the following situation: some complex logic like module cleanup spawns some confirmation dialog while in the process of modifying module data, and some other action gets launched via shortcut in the middle). If the keyboard hook was to send keypress messages to the GUI thread's message loop, one would handle the shortcuts where appropriate automatically, i.e. the main window handler would invoke the Export dialog, and if a modal dialog is already shown above the main window, the message would not even be processed by the main window, automatically resolving the superfluous window opening.
|2016-08-08 17:45||Rapture||New Issue|
|2016-08-08 17:47||manx||Relationship added||related to 0000713|
|2016-08-08 17:55||Rapture||Note Added: 0002575|
|2016-08-08 18:01||manx||Status||new => confirmed|
|2016-08-08 18:01||manx||Note Added: 0002576|
|2016-08-08 18:11||Rapture||Note Added: 0002577|
|2016-08-08 18:18||manx||Note Added: 0002578|
|2016-08-08 23:35||Saga Musix||Note Added: 0002580|
|2016-08-09 01:09||Rapture||Note Added: 0002582|
|2016-08-10 15:02||Saga Musix||Note Added: 0002589|
|2016-08-10 15:42||manx||Note Added: 0002591|
|2016-08-17 23:12||Saga Musix||Assigned To||=> Saga Musix|
|2016-08-17 23:12||Saga Musix||Status||confirmed => feedback|
|2016-08-17 23:12||Saga Musix||Product Version||=> OpenMPT 1.26.04.00 / libopenmpt 0.2-beta20 (upgrade first)|
|2016-08-17 23:12||Saga Musix||Target Version||=> OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first)|
|2016-08-17 23:12||Saga Musix||Note Added: 0002612|
|2016-08-23 22:42||Saga Musix||Status||feedback => resolved|
|2016-08-23 22:42||Saga Musix||Resolution||open => fixed|
|2016-08-23 22:42||Saga Musix||Fixed in Version||=> OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first)|
|2016-08-26 18:23||Saga Musix||Fixed in Version||OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first) => OpenMPT 1.26.05.00 / libopenmpt 0.2-beta20.1 (upgrade first)|
|2016-08-26 18:23||Saga Musix||Target Version||OpenMPT 1.27.01.00 / libopenmpt 0.3.1 (upgrade first) => OpenMPT 1.26.05.00 / libopenmpt 0.2-beta20.1 (upgrade first)|
|2016-08-26 18:24||Saga Musix||Fixed in Version||OpenMPT 1.26.05.00 / libopenmpt 0.2-beta20.1 (upgrade first) => OpenMPT 1.26.05.00 / libopenmpt 0.2-beta20.1 (upgrade first)|
|2016-08-26 18:24||Saga Musix||Target Version||OpenMPT 1.26.05.00 / libopenmpt 0.2-beta20.1 (upgrade first) => OpenMPT 1.26.05.00 / libopenmpt 0.2-beta20.1 (upgrade first)|