ModPlug Central

OpenMPT Development (Archive) => Bug Reports => Bug Report Archive => Topic started by: LPChip on August 22, 2006, 20:49:21

Title: .45 Keys overkill
Post by: LPChip on August 22, 2006, 20:49:21
As you know, MPT how has this very good and custom key-preset manager. It allows you to configure lots of keys etc.

It is soo good that it has unexpected side effects.

If I have the "load song" window open to load in a song, pressing F2 to rename a song, will put the current song to pattern editor (which is what I've set it to do according to IT standards) However, its not gonna bring me the "rename" feature in the loading window.

Another example: I've bough Electri-Q VST, and in order to get it registered, I needed to type in the registration code. You'll probably see it comming :P It was sending the notes to the assigned instrument. :lol:

Luckelly for me there is a stand alone version of the plug, otherwise I couldn't even register it :P

I'm sure there are other occasions where not sending keys to windows can lead to frustration.

EDIT: Partially fixed now since 1.18, File open dialog from OpenMPT does work as suspected. Its not interfering with OpenMPT at all.
Title: .45 Keys overkill
Post by: rewbs on August 23, 2006, 12:28:55
The first issue is a known bug, see 1.17rc2 release notes. Thanks for the reminder. Let's keep this thread to track that bug.

The second issue, however, is already resolved. There is a "send keys to plug" option under one of the  plugin window menus (can't remember what the menu is called now, maybe options).
Title: .45 Keys overkill
Post by: LPChip on August 23, 2006, 12:30:38
Ah okay... I never knew that. Maybe we should make a FAQ on the wiki for this kind of questions?
Title: .45 Keys overkill
Post by: rewbs on August 23, 2006, 14:08:36
For the plugin keys issue, feel free to amend the FAQ section on http://openmpt.xwiki.com/xwiki/bin/view/Manual/Plugins#FAQs about plugins.

I should make a section with known bugs, or perhaps just a link back to this forum.
Title: .45 Keys overkill
Post by: LPChip on August 23, 2006, 16:22:32
Done :)
Title: .45 Keys overkill
Post by: LPChip on August 14, 2007, 20:45:07
Am looking through old bugs again... What should we do with this one?
Title: .45 Keys overkill
Post by: Saga Musix on January 14, 2008, 16:04:43
Quote from: "Jojo"Full Version:
OpenMPT v1.17.02.49

Has the bug occured in previous versions? If yes, please specify version(s): (This option is optional, and doesn't need research. But in case you know...)
yep, present in all OpenMPT versions i have used so far, but not in the original MPT.

Description of the bug:
Some standard key shortcuts won't work in open / save dialoges. Some of them are sometimes quite important, like Ctrl+C / Ctrl+V (and i don't like to use context menus, really). Also, if I want to close such a dialog, I want to do this by pressing ESC (works in all other apps), but when I do so, the window gets closed AND the current songs stops playing.
I suggest that keys are not scanned while one of these dialogs is open so those shortcuts work again and ESC does not interfere with OMPT.
Title: .45 Keys overkill
Post by: Saga Musix on December 18, 2009, 20:03:27
With a bit of code cleanup, I think I can smash this really old bug so that keys are no more polled when a load/save file dialog is open. It's been there long enough.
Title: .45 Keys overkill
Post by: LPChip on December 18, 2009, 21:33:54
Quote from: "Jojo"With a bit of code cleanup, I think I can smash this really old bug so that keys are no more polled when a load/save file dialog is open. It's been there long enough.

Cool! Go for it. :) You have my blessing.
Title: .45 Keys overkill
Post by: Saga Musix on January 25, 2010, 22:25:51
Please confirm that this has been fixed in OpenMPT 1.18 release candidate (http://forum.openmpt.org/index.php?topic=3701.0). You can set the thread status to S=C yourself then.
Title: .45 Keys overkill
Post by: LPChip on January 26, 2010, 17:35:56
Not entirely fixed yet.

If I have a VSTi/VST window open which has a button to load in a patch, I get a windows file open dialog. Inside it, F2 still triggers the pattern view according to my keyset, not rename a file/folder.

I can of course  get around this by using Rewbs' suggestion. Not sure if you didn't fixed that on purpose though...

Am putting it back to open. Please let me know if it was intended.

For the record: I used Xlutop Chainer, and wanted to load a channel preset in one of the channels.
Title: .45 Keys overkill
Post by: Saga Musix on January 26, 2010, 18:16:04
Quote
I can of course get around this by using Rewbs' suggestion. Not sure if you didn't fixed that on purpose though...
I'm afraid it won't be possible to fix that. There is no such magical command like "detect all file dialogs that are created by VST plugins", so OpenMPT does not even *know* about them (the VST interface opens them by itself). You will have to resort to the "pass keys to plug" function for now. If you can agree on that, feel free to close the report.
Title: .45 Keys overkill
Post by: LPChip on January 26, 2010, 20:28:16
We could close it, but I have a feeling its not that hard to fix.

Would we really want to have the keys to be supported during any editing in a VSTi window?

The only keys I could find interesting are the keys to play notes, but others aren't. So it might be possible to say: when OpenMPT is not active (but one of its childs, like a vst window is, then don't pass special keys to the plug.)

If you think thats not possible, feel free to close the bug.
Title: .45 Keys overkill
Post by: Saga Musix on January 26, 2010, 20:44:29
you say you only need note keys, person b also wants to use play/stop, person c wants to have pattern navigation shortcuts available in addition, etc..pp... Who to believe? All of them of course. And that's why global shortcuts should still work in VST editors. Handpicking shortcuts is just so wrong. And blocking certain keys in the VST editor is wrong too, because what happens if person b has bound play/stop to F2? I hope that makes clear why "pass keys to plug" has been invented.