Getting spurious "shift keys" displayed in custom Menus


#1

I’m on the Mac, and displaying menus that I have loaded and saved through XML.

Unfortunately, all my “standard” commands like command-C, command-X etc are displayed as being command SHIFT C, command SHIFT X when they appear in the menus.

They display fine in the key mapping editor, and they execute fine from the keyboard, and the XML looks fine (no shifts unless I deliberately put them in). The only serious issue is that they are misdisplayed in the menu.

(Interestingly enough, if I press command-shift-x, I see the Edit menu flash but nothing happens, but if I press command-x, I don’t see the edit menu flash, but the command does go off…)

[EDIT: I should add that I didn’t see this issue before when I had “hard-coded” some of the keys - but there have been a lot of changes in my code since then, it’s conceivable that I broke sometime…!]


#2

Is this just because you’re using upper-case letters in your key definitions? (I thought I had an assertion in there to warn about that, but I might be imagining that)


#3

Yes, I had wondered about upper case letters in fact - because the XML file is stored with upper case letters which made me edgy. I wasn’t holding the shift key down when I created those events!

But in fact going in and editing those letters by hand and making them lower case had no effect and when I opened the keyboard command editor and looked at the file again, the key assignments had been saved with upper case again.

Note also that the commands were entirely entered in the keyboard editor, and look fine in the keyboard editor.Now, I confess that I am in fact using a hacked version of Juce’s keyboard command editor, but I believe it’s functionally identical, and none of that code path is touched when I’m in fact reading keyboard commands from saved XML files!

I tried entering “shift command c”, “option c” “shift option c” and things like that, and they worked perfectly OK and displayed fine. The system definitely understands the difference between command c and command shift c.

I think a key symptom is that the commands do work correctly, not as they appear on the menu, though the menu doesn’t flash when they go off - but when you try to execute the command with the extra shift key, the menu flashes but the command doesn’t execute. Unfortunately, the only code path I’ve managed to find is the one through the (working) command execution - I’m not sure how the menu entry commands are actually displayed…


#4

I can’t get it to go wrong… Can you give me some example code I could use to break it?


#5

Arg, sorry! :frowning:

Even easier, just tell me where to set a breakpoint. :smiley: Where’s the last spot that you tell the actual menu system what to display? I can’t find anywhere that anything is wrong - everywhere I set a breakpoint, everything seems right.

Or I’ll dive back in bigtime before I release and find it or find a test program. This isn’t yet in my central crosshairs.


#6

Well, you could breakpoint JuceMainMenuHandler::juceModsToNSMods… That’s not where I’d expect to find a bug, but it’s the place where the menu shorcut is created.


#7

Thanks, I’ll keep you posted as to the result!

Sorry for the flood of stuff, I went back and started working on “second-tier issues”. :smiley:


#8

So I didn’t make good progress on this issue but I did come up with a simple way to reproduce the bug.

If you have a program that allows you to make keyboard assignments and save them, try making a single keyboard assignment for the ! key (shift-1 on an American keyboard), saving it, and restoring it.

The XML serializing of the keyboard mapping manager saves the assignment as “shift + !” - but I’ve tried editing the file and putting in “shift + 1” and “!” and neither of those have actually triggered events on that key, though strangely the menus DO flash when I execute the commands, and I can successfully execute the commands from that same menu.


#9

On my mac it saved the keypress as “shift + !”, which isn’t the ideal way of expressing it, but it did all work correctly… Are you using Windows?


#10

Thanks for looking at this again!

I’m on a Mac. I get the same format of saved command as you do - the issue is that that key doesn’t work when I actually use it.

And the symptoms are weird. I actually have the key 1 and shift-1 (or !) independently mapped now (for an experiment). Pressing 1 works exactly as advertised - I see that menu flash, and the command is executed.

But if I press shift-1, I see that menu flash but the command is not executed - I can execute the command by pulling the menu down.

This is such a gross error that I’m having to believe that there’s something I’m doing that’s either out-and-out wrong, or (more likely in my experience) I’m using the interface in some way that’s reasonable to my warped little mind, but that you (Jules) never thought of.

The annoying part is that I had some of these commands working fine a couple of months ago - but I put in a ton of new functionality and updated my Juce which was somewhat old and it would be hard to really track back and find out when this broke.

So I’m going to first try to tweak the demo to reproduce this and report back (in a few days). If I can’t make the demo do the same thing, then, grr, I’ll burn that bridge when I come to it.

Have a good one!


#11

Hmm, can’t really think of anything that might break it. I was testing using the old jucer, which has a key-mapping panel in the preferences, so you could give that a spin to see if it works on your machine too.


#12

All right, I do have a reproducible issue in the Jucer, though I still don’t know why I’m getting the spurious shift keys on my cut/copy/paste.

If I assign a keymapping to shift-1 (that is, !) I don’t see anything on the menu - but if I assign it to shift-2 (that is, @), I see the symbols for shift-@ on the menu.

(It’d be nicer if it either showed @ or shift-2 on the menu…)

Also, I can’t seem to find where the old Jucer stores its keyboard preferences, so I can compare the file to mine.


#13

In NSViewComponentPeer::handleKeyEvent, there are a couple of DBG statements that you can un-comment, to print some info about the key events that arrive.

Unfortunately, if you do that, you’ll see that when you press shift + 1, the event’s “unmodified” character isn’t “1”, it’s “!” - so AFAICT, there seems to be no way to find out that the “1” key was involved. That makes it a bit tricky to fix!


#14

Oh, I should have been “hanging out” near that area of code again!

But the fact that these are displayed as e.g. shift-# rather than shift-3 is not really a “bug” - that would be a feature request instead.

The bug is that shift-! doesn’t even appear on the menu, but shift-@ does - even in the Jucer.

I’m going to look at that code again in detail so hope to have more to report before this thread is revisited…