CTRL+SHIFT+ Shortcuts sometimes not working in LabVIEW

[JackDunaway]

CTRL+SHIFT+E (and also CTRL+SHIFT+Z and CTRL+SHIFT+S) shortcuts do not work on a few of my virtual machines.

• Anecdotally, this appears to be limited to LV2011 and up
  
• All machines are Parallels 7 virtual machines running on OS X Lion
  
• Again, some work, and some don't - all with identical (as far as I can tell) VM keyboard and environment settings
  

What's interesting: CTRL+SHIFT shortcuts work just fine in other applications on the affected VMs - it's only LabVIEW that does not respond to the CTRL+SHIFT shortcuts. This leads me to believe that the Parallels VM information is a red herring, and that the same problem *might* affect a native Windows installation. Any ideas?

[JackDunaway]

OK, I have verified that CTRL+SHIFT+3 works just fine (That's CTRL+# which toggles grid visibility), yet CTRL+SHIFT+Z et al. still do not work. This would indicate keyboard modifiers are not being eaten by the VM, and that LabVIEW is handling at least one CTRL+SHIFT shortcut.

Why isn't it handling the others?? Am I misconfigured some way?

Can someone just do a sanity check for me on E, S, and Z on a machine running LV2012? Thanks!

[Aristos Queue]

Work fine for me on Win7 and on Mac 10.6.8.

By the way, you have just made me very happy... I had no idea ctrl+shift+E existed. That is a great shortcut... for everyone else: when you're on a VI, it finds that VI in the project tree.

[JackDunaway]

I'm on OS X 10.8 - could this be a difference, or is that another red herring?

And yes, CTRL+SHIFT+E makes me happy too, it's been sad not being able to use it

[GregSands]

All work fine for me on Win 7/LV 2012. Have you tried remapping the shortcuts in Tools/Options/Menu Shortcuts? In fact, trying to set new shortcuts there will show you whether the keystrokes are getting through to LabVIEW or not.

Edited August 23, 2012 by GregSands

[JackDunaway]

Have you tried remapping the shortcuts in Tools/Options/Menu Shortcuts? In fact, trying to set new shortcuts there will show you whether the keystrokes are getting through to LabVIEW or not.

Yes, I have tried remapping here. Things like CTRL+SHIFT+3 (from above, that's CTRL+#) and all punctuation (CTRL++, CTRL+>, etc.) will register just fine in this dialog; it's just the CTRL+SHIFT+Alpha keys that won't register.

[Aristos Queue]

I doubt it. We would have heard an earful from Urs when he visited at NIWeek if this were affecting Mac OS generally.

[JackDunaway]

I doubt it. We would have heard an earful from Urs when he visited at NIWeek if this were affecting Mac OS generally.

Granted, I'm having this issue in a Win7 VM, and Urs, more of a purist, says he likes to do things natively on the Mac (when we ate lunch together at NIWeek, he did admit to occasionally using Parallels, but will probably come to this forum and deny that conversation ever happened lest it tarnish his rep :-)

[MikaelH]

My Quick Drop Ctrl-Space, also stops working on some computers.

[JackDunaway]

My Quick Drop Ctrl-Space, also stops working on some computers.

So, if you go to "Tools >> Options >> Menu Shortcuts", does this dialog register CTRL+Space? Also, what's your OS/LabVIEW version?

[MikaelH]

So, if you go to "Tools >> Options >> Menu Shortcuts", does this dialog register CTRL+Space? Also, what's your OS/LabVIEW version?

Yes, it's linked to Ctrl+Space, and even if I change it to something else, it doesn't work on the computer that is giving me the problem.

BTW, I didn't dare to bring your Seeded business card into Australia, after a 25 hours flight I didn't want to get cought in custom ;-)

[JackDunaway]

BTW, I didn't dare to bring your Seeded business card into Australia, after a 25 hours flight I didn't want to get cought in custom ;-)

That was a good call on your part! Australia and New Zealand are apparently the only two countries in the world where my cards are contraband. "Sorry, mate"

[JackDunaway]

Thanks to Justin for helping me debug this again today - but still no go

Things I've tried:

• Using CTRL+SHIFT+Alpha shortcuts in other applications (Notepad++ works fine)
  
• Using CTRL+SHIFT+3 shortcut in LabVIEW works fine (It's just CTRL+SHIFT+Alpha shortcuts that have the prob)
  
• Setting all VM settings to a known good VM (via text-diff on settings file within the VM package) (this feels like a red herring)
  
• Using the Input VIs in a simple LabVIEW program to see if it can register CTRL+SHIFT+Alpha keypresses; it can
  
• Remapping modifiers on the Mac side to act like the CTRL key
  
• Swapping keyboards with a traditional Windows keyboard
  
• Remapping CTRL+SHIFT+E to be just CTRL+E - then "Show in Project" worked as expected (just a sanity check, to ensure it is indeed a problem with registering the shortcut, not the invoking the action itself)
  
• Using every imaginable combo of FN, CTRL, ALT, and CMD
  
• Pressing SHIFT+CTRL+E (notice the order)
  
• Using the Left and Right Shift keys
  
• Removing LabVIEW.ini to let it regenerate
  
• Reinstalling a fresh copy of LV2012 32bit
  

Here's a piece of information that may or may not be germane: when I press CTRL then SHIFT then E, as soon as I hit E the mouse turns from the cross-hair to the panning hand if hovering over the FP or BD, and remains the panning hand as long as I hold down CTRL+SHIFT (I can release E, or keep it help, doesn't matter. And 'E' is any arbitrary key). Also, if I hold down CTRL+SHIFT and then click anywhere, the cursor changes from cross-hair to panning-hand on the first click, and remains the panning hand as long as CTRL+SHIFT is help.

If this were StackOverflow, I'd offer bounty on this problem. Any more troubleshooting suggestions??

[todd]

Perhaps Parallels isn't sending all of the HID Keyboard information to the guest OS.

One way to see may be to use System.Runtime.InteropServices.Marshal.ReadInt32().

I don't know it well enough to post code, though.

[JackDunaway]

Perhaps Parallels isn't sending all of the HID Keyboard information to the guest OS.

Does this following VI disprove that it's Parallels' fault? Or is this VI using some other keystroke reading mechanism other than the way LabVIEW reads global shortcuts?

**EDIT: By the way, thank you for responding, Todd! I'm still desperately looking for any news avenues to explore to solve this issue.

Edited September 4, 2012 by JackDunaway

[todd]

Short answer: I don't know.

That VI calls a LV function called getKeyboardState, which may be an abstraction of Microsoft's DirectInput API. If so, it returns a list of keys that are pressed. But that may be separate from the "Modifier Keys" bitfield in a keyboard report.

Just poking in the dark, here, and drawing a target that someone who knows better will hopefully shoot down

[Rolf Kalbermatter]

Short answer: I don't know.

That VI calls a LV function called getKeyboardState, which may be an abstraction of Microsoft's DirectInput API. If so, it returns a list of keys that are pressed. But that may be separate from the "Modifier Keys" bitfield in a keyboard report.

Just poking in the dark, here, and drawing a target that someone who knows better will hopefully shoot down

The LabVIEW key handling will definitely not be based on DirectX access but directly work on the events returned by Windows in its internal GetMessage() loop. I haven't seen such an issue yet, but I'm not using Macs much, and definitely not with Parallels. I do use Virtual Box quite regularly but with a Windows host and Windows and Linux guests. Would love a Mac guest too but that is just to much trouble to get working reliably. And those VMs sure can do some weird things when passing down events and other stuff to the guest OS. For instance I can reliably crash my computer completely and without even any BSOD if I startup the Windows 7 64 Bit VM and my host Windows system has been operating for quite some time. After a fresh restart of the host it never crashes.

[Yair]

Does this following VI disprove that it's Parallels' fault?

Not necessarily. From my own battle with keyboard shortcuts, I seem to remember that those VIs and the event structure behaved differently, but I wouldn't swear on it. Try checking the key down event (you'll probably need the modifiers terminal to see those keys).

[JackDunaway]

Not necessarily. From my own battle with keyboard shortcuts, I seem to remember that those VIs and the event structure behaved differently, but I wouldn't swear on it. Try checking the key down event (you'll probably need the modifiers terminal to see those keys).

You may be onto something here. This is the result I get when pressing CTRL+SHIFT+E:

And here's the snippet in case someone else is able to run on a known-good machine, to compare results:

It's suspicious that in my result above Char is '0' (instead of '69') and VKey is 'Ctrl' (instead of 'ASCII').

[todd]

Running that VI natively, here, it shows 0x18 - but it also performs the action (This VI in Project). I mentioned DirectX as the way that "Acquire Input Data.vi" probably works within the guest OS as a way for LV to see those inputs. The event structure probably ties in deeper than that. I imagine Parallels injects keys using a driver that is installed in the guest - or somehow uses "SendInput". Either way, it's a very tricky thing to manage. KeyOn and KeyOff need to be sent in such a way to avoid repeating keys, neglecting to send KeyOff can leave stuck keys, etc, etc. One of the Parallels threads mentions trying:

Virtual Machine -> Configure -> Options -> Advanced -> Optimize modifier keys for games. Oh, I have an old Parallels license around somewhere at home - maybe I can play with it tonight.

[JackDunaway]

One of the Parallels threads mentions trying: Virtual Machine -> Configure -> Options -> Advanced -> Optimize modifier keys for games. Oh, I have an old Parallels license around somewhere at home - maybe I can play with it tonight.

That got me really excited, enough to restart the VM and try it out, but no go It's worth mentioning that Parallels 8 came out a couple days ago, and even though the features were not enticing, perhaps it's worth a shot to try to fix this problem (now I'm beginning to wonder if it's a Parallels prob after all...)

[JackDunaway]

OK, a little further investigation. I'm trying to directly inject CTRL+SHIFT+E via user32.dll SendInput, and it's still not working (though this could be a programming error on my part).

The following snippet creates two simulated keystroke events: CTRL+SHIFT+E (An array of 6 events, CTRL down, SHIFT down, E down, E up, SHIFT up, then CTRL up) and then the simpler CTRL+E (an array of 4 events) with two buttons on the FP.

The CTRL+E shortcut works just fine; when I click the button "FAKE CTRL+E" the Block Diagram window becomes frontmost. However, when I click "FAKE CTRL+SHIFT+E" nothing happens.

One more problem; this could be a programming error, or a problem with my test rig - in the snippet, the Key Up events are not honored (i.e., dwFlags=2 does not properly KeyUp as per http://msdn.microsoft.com/en-us/library/ms646271(v=vs.85).aspx ). CTRL and SHIFT are still held down, so to "unstick" these keys, I physically press them on the keyboard. Be forewarned, that if you run this snippet, you may need to do the same.

Does this tell me anything? Does this take Parallels out of the equation? Have I made programming errors that need to be corrected? <headscratch />

[todd]

I don't have 2012 on this box. However, I think sending an array of pInputs is too big. Try sending one keyup/down and one wVk at a time.

I found the guts of this dll call somewhere on the NI forums.

user32dll.zip

Edit: Oh, I sped through and missed your array indexing. Perhaps try the U8 data format in the zip file.

Edited September 5, 2012 by todd

[JackDunaway]

I don't have 2012 on this box. However, I think sending an array of pInputs is too big. Try sending one keyup/down and one wVk at a time.

I found the guts of this dll call somewhere on the NI forums.

This isn't working for me at all... dug through the source for about 10min, but couldn't find any obvious reasons why it would not send keystrokes. Did the snippet that I posted work on your machine? (Especially curious about the FAKE CTRL+SHIFT+E button - because CTRL+E button worked for me... it's just the KeyUp's that were failing)

[todd]

Sorry, change the constant outside the sequence to True, then swap the cases for the sysexec.vi. Running that shows me the VI in the project (since I have a project open).

The snippet you posted sent key downs, but not key ups. Casting one of your clusters to a U8 array shows a different number of Bytes than the method in the zip file. You may need to adjust the representations, or pack the Bytes as in the zip file helpers.