CTRL+SHIFT+ Shortcuts sometimes not working in LabVIEW

[JackDunaway]

Casting one of your clusters to a U8 array shows a different number of Bytes than the method in the zip file.

Oops, you're right, I had wVk as I32 but it needed to be I16. Now, the problem is fixed and Key Up works, but I've still got the same problem; programmatically invoking CTRL+SHIFT+E does not show the VI in the project. Likewise, I tried changing this to 'S', and Save worked but Save All did not. Here's the fixed snippet:

Also, I went ahead and upgraded to Parallels 8, and this has not helped

So, if CTRL+SHIFT+E via SendInput is not working, can we say that Parallels brokering keystrokes from the host into the VM is not the problem here?

[JackDunaway]

Latest update:

• Created a new Win7 Ultimate 32bit VM from scratch, and re-installed LV2012 32-bit f1. Still does not work.
  
• Tried "LVdebugKeys=True" in LabVIEW.ini on a whim... as it turns out CTRL+SHIFT+D+H does not work either.
  
• Validated with 4 other Windows programs that CTRL+SHIFT+Alpha shortcuts work, but...
  
• ...tried CTRL+C and CTRL+SHIFT+C in VIPM, and CTRL+SHIFT+C does not work! Does this again point toward a LabVIEW-only problem?
  

[Rolf Kalbermatter]

Latest update:

• Created a new Win7 Ultimate 32bit VM from scratch, and re-installed LV2012 32-bit f1. Still does not work.
  
• Tried "LVdebugKeys=True" in LabVIEW.ini on a whim... as it turns out CTRL+SHIFT+D+H does not work either.
  
• Validated with 4 other Windows programs that CTRL+SHIFT+Alpha shortcuts work, but...
  
• ...tried CTRL+C and CTRL+SHIFT+C in VIPM, and CTRL+SHIFT+C does not work! Does this again point toward a LabVIEW-only problem?
  

Well if it would be a LabVIEW only problem it would also happen on non-Parallels installation and as far as I can see that is not the case. It must have to do with the particular way Parallels generates dead keys in its keyboard virtualization driver and how LabVIEW interprets them. That LabVIEW most likely is not just doing the normal standard processing is obvious, but if that is illegal in terms of the Windows API and just happens to work on all real world hardware scenarios or if Parallels is messing up somehow when simulating the keyboard BIOS interface is not possible to say at this point.

If you really want to spend more time, I would try to install VirtualBox and check with that.

[JackDunaway]

Well if it would be a LabVIEW only problem it would also happen on non-Parallels installation and as far as I can see that is not the case. It must have to do with the particular way Parallels generates dead keys in its keyboard virtualization driver and how LabVIEW interprets them. That LabVIEW most likely is not just doing the normal standard processing is obvious, but if that is illegal in terms of the Windows API and just happens to work on all real world hardware scenarios or if Parallels is messing up somehow when simulating the keyboard BIOS interface is not possible to say at this point.

If you really want to spend more time, I would try to install VirtualBox and check with that.

But this does not explain the WinAPI SendInput calls from within LabVIEW not even working - right? (By the way... I'm creating a new VirtualBox Win7 machine and a Parallels WinXP machine as we speak.)

[Rolf Kalbermatter]

But this does not explain the WinAPI SendInput calls from within LabVIEW not even working - right? (By the way... I'm creating a new VirtualBox Win7 machine and a Parallels WinXP machine as we speak.)

Since you can not look at the source code of both LabVIEW and probably more interestingly the Windows kernel and how it routes SendInput() events along the BIOS keyboard interface, it is hard to say where the problem could be (not that insight in both source codes would likely help much without VERY intense study. This is most likely one of the more delicate parts of the Windows kernel, where a lot of code has accumulated over the years for backwards compatibility, bug circumvention and circumvention of bug circumvention and so on).

[Justin Goeres]

I'm just dropping by to register my name on the small (but growing?) list of people who've seen the same problem as Jack.

In my case, I had the following:

• Windows 7 64-bit VM (in Parallels 7)
  
• LV2011
  

I saw exactly the same symptoms Jack describes; they began to appear when I upgraded the VM from Parallels 6 to Parallels 7. In my case, I fought with it for about 2 full days then finally gave up and rolled back to Parallels 6 from a backup.

Recently I was forced to upgrade to Parallels 7 (required for OS X 10.8 Mountain Lion compatibility). This time, as if by magic or dumb luck, the problem has not recurred. However, given that Jack & I have both seen this I'm sort of living in fear of every new Parallels or LabVIEW update that I apply.

[JackDunaway]

I'm just dropping by to register my name on the small (but growing?) list of people who've seen the same problem as Jack.

Thanks, Justin!

If you really want to spend more time, I would try to install VirtualBox and check with that.

OK, after some hiccups finally got LV2012 32-bit running on a Win7 x64 VirtualBox, and CTRL+SHIFT+E works just fine. This might indicate that it's specifically a LabVIEW-Parallels interaction gone bad... but would not explain how/why Justin and I are both running "identical" setups, yet his problem was fixed once upgrading to Parallels 8 and mine remains. (I use the term "identical" very, very lightly)

[JackDunaway]

For completeness, this problem still exists on Windows 8 and Windows XP running different combinations of LV2009 to LV2012. It seems firmly related to some incompatibility between LabVIEW and Parallels and/or OS X, which didn't exist until sometime about 6months ago, and was most likely due to a change from either Parallels or OS X.

One shining glimmer of hope: a workaround exists using AutoHotKey and remapping favorite CTRL+SHIFT+Alpha shortcuts to CTRL+SHIFT+punctuation shortcuts not currently in use by LabVIEW. The AutoHotKey command "^E::," means "when I type SHIFT+E, instead inject a comma into the keyboard input stream". And that way, CTRL+SHIFT+E becomes CTRL+<, which is the new binding in LabVIEW for "This VI in Project".

Suboptimal solution, but at least the severity has been downgraded to about-as-inconvenient-as-a-pizza-burn-on-the-roof-of-my-mouth. Will continue to investigate, but hopefully this workaround will keep this of-generally-little-interest thread quiet for a while

[Omar Mussa]

FWIW - I just created a new Parallels VM and am running LV 2013 (32-bit) on a Win7 x64 machine and I have the exact same problem.  Its a real pain and the only workaround is manually remapping shortcuts which really sucks - I remapped CTRL+SHIFT+E and CTRL+SHIFT+W immediately - the other three key combos aren't so critical to me ...

[JackDunaway]

Here we are are while later... I'm still having this problem with all versions of LV on all VMs. AutoHotKey has been an "ok" workaround in the meanwhile -- i've chalked it up to the cost of doing business. I've pinged some additional Parallels users, and they're reporting the same prob with LabVIEW -- perhaps they'll chime in.

[ElijahKerry]

I'm seeing the same issue myself - in fact, I had to give a QuickDrop demo in Boston this week using a PC because I couldn't figure out a solution.

 

I'm pretty sure this isn't LabVIEW's problem, so I'm not going to ask R&D to dig into this (yet).  That being said, I can't find any settings in Parallels 7 that appear to fix this.  

 

Anyone give Parallels 8 a shot yet?

[JackDunaway]

Eli, I've been running Parallels 8 since it came out (last year or so?) with this issue; Parallels 9 just came out a few weeks ago, and I'm yet to upgrade to try that (waiting for the dust to settle on that and Mavericks also).

 

"I'm pretty sure this isn't LabVIEW's problem" << Anecdotally, I think it might be LabVIEW, since every other application in the VM accepts 3-key shortcuts, including CTRL+SHIFT shortcuts -- it's just LabVIEW that's having problems. For instance, open Chrome in your VM, go to a webpage, exit that page, and hit CTRL+SHIFT+t -- the tab will re-open. Likewise, CTRL+ALT+s and CTRL+SHIFT+s works in Notepad++

[Omar Mussa]

I have one more data point to report ...

 

Running from the same Mac OSX 10.9 and Parallels 9, I have two Win 7 x64 VMs.  One of them I built recently and another I built a long time ago.  The older VM allows the CTRL+SHIFT shortcuts (tested with CTRL+SHIFT+E) but the new one does not.  The older VM is running LV 2011 and I did not update parallels tools.  The old VM was running Parallels Tools 7.0.15004 when it was working.  I took a snapshot and then upgraded parallels tools to latest version.  After upgrading to latest Parallels Tools CTRL+SHIFT+E still works.

 

Note that Justin mentioned that in LV2011 on his VM CTRL+SHIFT+E did not work - so there must be some VM or Windows setting that is affecting LabVIEW but its really not obvious to me what the difference is between my two VMs.

[Justin Goeres]

Ah, how I love this issue. Since I keep getting mentioned (and since Eli is new to the problem) I'll summarize what I know.

 

And Eli, if there's anything I can do to help work this inside NI, please ping me privately. I would be happy to help, and I've banged my head against this for quite some time.

 

I'm seeing the same issue myself - in fact, I had to give a QuickDrop demo in Boston this week using a PC because I couldn't figure out a solution.

 

I'm pretty sure this isn't LabVIEW's problem, so I'm not going to ask R&D to dig into this (yet).  That being said, I can't find any settings in Parallels 7 that appear to fix this.  

 

Anyone give Parallels 8 a shot yet?

 

Like Jack said, I'm pretty sure this actually is LabVIEW's problem. That's based on a couple datapoints:

• LabVIEW is literally the only application this problem appears in. Additionally, the exact same shortcuts (Ctrl+Shift+E, Ctrl+Shift+W, etc.) do work in other apps in the VMs. This makes it extraordinarily difficult to get help from the Parallels people, since no one but LabVIEW users (on Parallels) can reproduce the problem, and it doesn't even affect 100% of us!
• There are a few apps (Jack pointed me to one but I forget it now) that display keypress captures in Windows. These tools all report that the keys seem to be caught correctly by Windows, so whatever is going on seems to be happening inside Windows on the VM, not at the Mac/VM boundary.
  

My gut says that the cause is probably wrapped up somewhere in an interaction between Parallels Tools and... I dunno... something in the way LabVIEW registers for keypresses?

 

I have one more data point to report ...

 

Running from the same Mac OSX 10.9 and Parallels 9, I have two Win 7 x64 VMs.  One of them I built recently and another I built a long time ago.  The older VM allows the CTRL+SHIFT shortcuts (tested with CTRL+SHIFT+E) but the new one does not.  The older VM is running LV 2011 and I did not update parallels tools.  The old VM was running Parallels Tools 7.0.15004 when it was working.  I took a snapshot and then upgraded parallels tools to latest version.  After upgrading to latest Parallels Tools CTRL+SHIFT+E still works.

 

Note that Justin mentioned that in LV2011 on his VM CTRL+SHIFT+E did not work - so there must be some VM or Windows setting that is affecting LabVIEW but its really not obvious to me what the difference is between my two VMs.

 

Let me fill in a little more background on this, since I've been dealing with this issue for a long time.

 

First off, anyone who is affected by this issue take note: whatever your experience is, it's basically a single sample. Several times I've thought I figured out a pattern to the issue, but I've always found a counter-example usually from my own later experience.

 

Here's what I know for sure, based on direct personal observation:

(Definition: by "the issue" I mean "LabVIEW doesn't recognize 3-key shortcuts, e.g. Ctrl+Shift+E, Ctrl+Shift+W, Ctrl+Shift+Z, etc., when running in Parallels.")

• The issue has been happening since at least Parallels 6. I have personally witnessed it on every recent release of Parallels (6, 7, and 8) except Parallels 9, but obviously Omar has seen it on Parallels 9.
• The issue occurs in Windows XP VMs as well as Windows 7 VMs.
• The issue occurs most frequently when upgrading VMs between versions of Parallels, but also can occur on brand-new VMs.
• The issue is only triggered by upgrading or new-VM creation. I.e. the issue doesn't just spontaneously occur out of the blue.
• Once a VM is affected by the issue, it's affected forever. Upgrading to an even later version of Parallels will not "fix" it.
• The issue is not related to a specific version of LabVIEW. I've seen VMs with anything from LabVIEW 2009 through 2012 affected, and it (rather obviously) affects all versions of LabVIEW on a given VM.
• If a VM becomes affected by the issue when upgrading, I have had some success in rolling back to a non-upgraded Time Machine backup of the VM and re-running the upgrade. I.e. there seems to be some "luck factor" in whether a given upgrade works out or not.
  

As you can understand, this is one of the most inscrutable and frustrating things about running LabVIEW in Parallels.

Edited November 25, 2013 by Justin Goeres
Removed double-post due to DB error.

[JackDunaway]

I can second all Justin's anecdotes. Recently, this issue prevented one important workflow -- CTRL+SHIFT shortcuts are required to take a Peek at the good ol' Heap.

[kars10]

Ran into this problem today and was greatful to find this thread, even if we don't have a fix yet. At least I'm not alone in this strange behavior. 

Here's my setup:

Mac running OS X 10.9.1

Windows 7 Enterprise running in a Parallels VM

Parallels/Parallels Tools version 9.0.23350

LabVIEW 2013 (13.0f2)

 

 

Here's something interesting that I've noticed:

 

Regarding Jack's comments in Post #13

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 held.

I think this may be somewhat normal behavior.  Check out this section from the LabVIEW help on "Selecting a Tool":

"If automatic tool selection is enabled, you can select specific tools in the following ways:

Move the cursor over any open front panel or block diagram space and press the <Shift-Ctrl> keys to temporarily switch to the Scrolling tool."

 

In my experience, I can get two different behaviors in this regard, depending on the setting found under Parallels > Configure... > Hardware > Mouse & Keyboard > Keyboard.

If I choose "Optimize for games", pressing CTRL+SHIFT will immediately change the tool to the Scrolling tool (panning hand).

If I choose "Don't optimize for games", pressing CTRL+SHIFT does not seem to have any effect.  Only when I add a third key (like "E") to the group does the tool change to the hand (as Jack described).

 

From the Parallels help:

"Choose Optimize for games from the Keyboard menu if you actively use the modifier keys Option (Alt), Ctrl, and Shift in action games. If you choose this option, signals from these keys will be processed faster."

 

"Optimize for games" doesn't seem to be a complete fix, but it makes some other odd behaviors better.

For example, with the setting on "Don't optimize for games", I've found that if I click and drag an item and then press CTRL to make a drag-copy, it turns into a regular drag-move, not a copy.  Switching to "Optimize for games" fixes this issue.

[Michael Aivaliotis]

I just wanted to add my observations. First off, I don't have this problem at all. All works fine for me in any Parallels VM.

I'm running:

 

Parallels 9.0.24217

LabVIEW 2013

Windows 7 or XP

 

However, I did have an issue where I couldn't perform actions that required a combination of ctrl+shift+mouse action.

For example:

• Ctrl-Shift-click (drag)
• Ctrl-Shift-resize
• Ctrl-Shift-Run button (mass compile all)
  

It's not that many, but the last one is critical sometimes to fix LabVIEW relinking issues and project crashes.

In any case, Google brought me to this help article:

http://kb.parallels.com/en/116170

 

So I basically disabled both checkboxes in that dialog (which I didn't even know existed) and that fixed my problem!

I don't know if this is related to the issues you guys are seeing but perhaps you could try it. There are also some other settings in there that can be fiddled with.

 

[kevintho]

I too have been struggling with this inconvenience for quite some time.  I can go for several weeks just ignoring the issue, and then something comes up where it causes me to descend into a battle of will and spend at least a couple hours re-trying settings and experimenting to see if I just missed something the last time around.  The lack of Ctrl-Shift-G functionality and quick drop shift keyboard shortcuts are particularly discouraging.  It's all very annoying, but not so annoying that I'm willing to stop using VM's in order to gain back the use of the shortcuts that native OS users enjoy.  (VM's are a way of life.  I don't know how I ever managed to survive without them...)

 

Unfortunately for me, Michael's suggestion (and good fortune) of changing the Parallels' Mouse Shortcuts settings to disable 'Secondary click' and 'Middle click' does not fix the problem for my setups.  I have several development Mac systems with a variety of Lion, Mountain Lion, and Mavericks, all currently running Parallels 9.0.24172.  I have many WinXP and Win7 x64 VM's.  Some are run from the local hard drives, others on an external drive used for portability between Mac development systems (with the VM's running directly from the external drive -  it does work very well with almost no performance hit, and what a convenience).  The bottom line is that nothing I do or change seems to fix this issue on any of the VM's across any of the development machines.

 

For me, the problem has always existed, starting with Parallels 7, then on Parallels 8, and now on Parallels 9.  LabVIEW seems to be the only application I've found so far that is affected, from versions 7.1 all the way through LV 2013.  As Jack mentioned earlier, other applications like Notepad++ do not have this issue.

 

I have used VMWare Fusion in the past, but have not upgraded in a long time.  I'm wondering if the latest VMWare Fusion might behave differently.  I understand from an earlier post that VirtualBox VM's do seem to exhibit the same problem.  Has anyone here tried a recent version of VMWare Fusion to see if there are similar issues?

[barold]

I seem to be having this problem as well. With one major difference though, it happens on my Dell Laptop with a native install of LV2013 SP1f2. I also have the issue on my Parallels VM, but first saw it on the Dell (the VI's and the issue were on the Dell before I even owned the Mac).

 

I find it most intrusive when I try to control drag objects to copy them, and then I can't ctrl-z to undo it either.

 

EDIT: It is very intermittent on both machines. Sometimes works on the 1st/2nd try. Sometimes it wont work at all.

Edited July 11, 2014 by barold

[kevintho]

Parallels 10 was released today for those wanting to upgrade from Parallels 9.  Optimism abounds. )  I don't know if this new version will fix this problem, but there's reason for hope.

 

Has anyone here experimented with Parallels 10 yet?

[hooovahh]

I don't want to go off topic...but you have 7 posts...been registered since 2005...and you are a premium member.  Congratulations to you sir, and thank you for supporting this forum.

[kevintho]

It is my pleasure to support the forum.  This community is a tremendous resource.

[barold]

 

"Optimize for games" doesn't seem to be a complete fix, but it makes some other odd behaviors better.

For example, with the setting on "Don't optimize for games", I've found that if I click and drag an item and then press CTRL to make a drag-copy, it turns into a regular drag-move, not a copy.  Switching to "Optimize for games" fixes this issue.

 

kars10, I am getting the exact opposite results as you. Or at least I thought so at first. Now I cannot get LabVIEW to show the issue at all no matter the setting.

 

This is really starting to drive me bonkers. It is not consistently repeatable one way or the other for me. It will appear, I'll play with some settings, maybe close a VI or two and I will think that it fixes it. Then after 5 minutes, an hour, 6 days, maybe a month later it will come back.

 

My boss is now experiencing the same issue on his Surface Pro 3 running Windows 8.1 and LV 2014. Mostly with CTRL+C and CTRL+V shortcuts.

[shoneill]

I have seen discrepancies between the "Input" VIs and the built-in LV event structure before.

 

I connect to my work PC via VPN and quite often after working from home for a day I'll come back to my PC in the office and find out that the mouse button information is not working via the "Input" VIs (mouse AXIS information is fine funnily enough) but they work absolutely fine everywhere else (Including LV itself).

 

I've often thought there must be some kludgy code down in the depths somewhere.  Or it could be a M$ problem with switching of contexts or something... I actually have absolutely no idea.

[Justin Goeres]

Has anyone here experimented with Parallels 10 yet?

 

And the beat goes on. I have now experienced this problem ("Ctrl+Shift keyboard shortcuts don't work in LabVIEW") twice on completely different Parallels 10 VMs...

 

(1) I have a years-old Windows 7 64-bit VM that has never exhibited the problem, across multiple Parallels updates (probably since Parallels 7). The other day I upgraded it to Windows 8.1 64-bit (which required reinstalling all my apps) and when I reinstalled LabVIEW 2014 I discovered it was affected by The Problem. (Edit: Note that this VM did not exhibit The Problem in Parallels 10 at first – the issue appeared when I updated it to Windows 8.1.)

 

(2) I created a new Windows 8.1 64-bit VM from scratch, and upon installing LabVIEW 2014 I discovered it was affected by The Problem.

 

So whatever the root cause of this issue is, it clearly hasn't gone away in Parallels 10.