JackDunaway

Thanks for pointing out this thread, it's got some good topics (with limited bandwidth, I had shied away from that thread on principle, since "QSM in a subject on LAVA" usually equals "religious debate" ) And the answer to the question "how is that different from anything else" is... ... just wait until the next evolution where you use User Events for both control and response! My proclivity to User Events is perhaps explained by a background focusing on UI and UX design. The ability to combine interprocess commands with UI commands into a single event handler structure is syntactical nirvana. And again, the fact that the User Event Ref and the Event Registration Refnum are two discrete entities - rather than a Queue, where the sender and receiver share the same reference - decouples processes and simplifies philosophical (and practical) issues like ownership and lifetime.

Sure! Consider a simple DAQ loop, generating data. Consider one of many types of listeners (consumers)... a logger, a UI, a server that re-broadcasts the event over a network. The DAQ loop can run headlessly and independently of those subscribed to its messages, and they can come into and out of existence as they please.

Just providing an example below to substantiate this vague statement. NOTE: To demonstrate a growing mailbox, this VI creates a memory leak of 10MB/sec once a "Register Mailbox" button is clicked. It can be stopped by hitting Suspend, Unregister, Kill the Messenger, or STOP buttons. Also note that in a real application, you would handle the events once registered and memory usage would stay appx net-zero; this VI is meant to grow memory unbounded just as a demo. Try a couple of scenarios, watching the memory usage each time. Register a mailbox, let it run a moment. Suspend it. Register it again. Suspend it. Unregister it. Register a mailbox, let it run a moment. Kill the messenger. Note that the memory usage has stayed constant, because the mailbox still exists. Unregister the mailbox. Note memory usage drops to 0. Try combinations of registering two mailboxes, and note the one-to-many behavior; mailboxes are independent of each other, and independent of the messenger. (There's one behavior I do not understand - when both mailboxes are registered, one would think the memory leak should be 20MB/sec instead of 10MB/sec, but it remains at 10MB/sec. Any takers on explaining this? Is an optimization being applied for unhandled event queues?) Note that when the VI is first run, messages are being sent, but disappearing into the ether! This is a powerful behavior to have the messenger unaware of whether or not it will create a memory leak if its messages are unhandled (queues don't have the ability to "fire blanks"). For these reasons (decoupling messenger from mailbox, the ablity to fire blanks, and one-to-many), I prefer User Events for interprocess messaging.

By convention, the Event Registration Refnum is wired exclusively to one and only one Event Structure, and this wire is never branched -- the exact same convention as the "Register for Events" node. The difference? The User Event ref remains private to the containing Messenger class; no naked refs are exposed to be manipulated with User Event prims by callers.

My only recommendation is to never do this. Event registration refnums are strictly typed and can't be changed easily as you implied. It might seem like a minor inconvenience now, but you can really end up in a bad situation if you start passing those registration refnums all over the place. Plus, why would you want to pass an event registration refnum around? There should be a one-to-one relationship between event structures and registration refnums. Make a typedef cluster of your events refnums, pass those into a subvi, then obtain a registration refnum from the cluster in the same VI you need it. There's a valid reason to pass an event registration into a SubVI to be SubPanelled, and that's when you want to "pre-stuff" the mailbox with some events prior to the SubVI running. This is because the "Register for Events" node is unaware of User Events that have been sent along a User Event Refnum -- which incidentally demonstrates the beauty and power of separating the messenger (User Event Ref) from the mailbox (Event Registration Refnum). Yes, I agree it's a pain if you change the datatype of the message; or if you want to rename the case label on the Event Handler Structure. Coerce to Type ostensibly handles the second problem; the first problem is solved by convention (don't change your mind on datatype! ).

And don't forget the idea by jcase on the LV IdEx that could get rid of 75% of this syntax!

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

Thanks, Justin! 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)

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

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?

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?

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)

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 />

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

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').

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.

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??

If only this were my first .NET Mugatu Moment recently ... *Mugatu Moment - an internal struggle so confusing and contradictory that, neither absolutely nor ostensibly, one is unable to determine whether one is indeed "taking crazy pills"

Nope; this does not appear to be an upgrade mutation bug. Brand new install of LV2012, brand new code. I just accidentally stumbled upon it coding with sausage fingers. You can drop a .NET constructor and check yourself; I'm curious if it exists in LV2011 or previous.

This took a decent amount of debugging and headscratching to figure out why a particular .NET call kept failing. I inadvertently discovered and wired a "vestigial" output terminal that exists on .NET Constructor Nodes in LabVIEW 2012. Interestingly, this output terminal returns the same datatype as the "real" output terminal, yet does not return a valid ref. Pretty sure this is a CAR-able bug, but just documenting behavior here just in case someone else runs into this. (Can you think of possibilities to exploit this as a feature??) Here's a 47sec YouTube video with no sound; Vestigial Terminal at 25sec: ...and for the sake of organic search: Error 1172 - "LabVIEW: A .NET exception occurred in an external assembly. For information about correcting this error, copy the following exception (in bold), and search the Microsoft Developer Network (MSDN) Web site or the Web for a possible explanation." And in case the resolution for this "error" and my "bug" was not clear: I just had to rewire the terminal to the "correct" output. Further, my choice of .NET assembly, constructor and property for the demonstration was arbitrary; this appears to affect all .NET Constructor Nodes.

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"

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

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 :-)

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.

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