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

Yep, reproduced this in LV2011SP1f2, LV2010SP1, and LV2009 (all 32-bit). Guess you're the first lucky guy to find this - and know about it.

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"

Did you find this in code you loaded from a previous version of LabVIEW, by chance?

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.

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"

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?

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

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.

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

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!

The two most important pieces of hardware for a successful day of LabVIEW coding are a Mac and a comfy pair of socks... but coming in close third is pair of noise-cancelling headphones! For the 2012 LAVA BBQ, Wirebird Labs LLC - fresh to the LabVIEW Tools development arena - will be giving away a set of Bose® QuietComfort® 15 Acoustic Noise Cancelling® Headphones. Inline cord controls make it a viable replacement for iPhone calling, and Songza has never sounded better!

I’ve personally vetted and enjoyed my own pair during extreme LabVIEW dev sessions, but heed this warning: a mere tap on the shoulder from a well-wisher becomes a terrifying sneak attack when you're engrossed in your alternate execution space of audial serenity.

Pictured below: rare photo of a feral graphical developer in his natural habitat, caught unawares due to the headphones.

As the 2010 that guy, I can confirm you do not want to be that guy.

Mr. Mike was that guy, and I was that guy after that guy. I'll say once, I'll say twice. You don't want sloppy seconds when it comes to BBQ tix. (Long story short, in 2010 I bought the ticket off of a kind LAVA moderator willing to give up his ticket, who "Doesn't like BBQ anyway")

Hearty congratulations to Mr. and (especially) Mrs. jgcode. Babies are the best.

I'm unable to write comments on that document <headscratch>, so I'll ask here: Could you post a PDF in addition to (or in lieu of) the docx? (The doc references embedded pictures, but I'm not seeing any - probably a portability prob that hopefully PDF can solve.)

Alternatively, maybe paste the RFC into the community page itself, in case the Community doesn't index docs?

Thanks!

I would love to come, but I have to bring my wife and kids to NI week this year since her 40th birthday is at this day

LAVA BBQ is a great place for the LV Community to help your wife to celebrate her 30th birthday!

Count me in - ticket bought! This was certainly the highlight of NIWeek 2011 last year. Can't wait to hear more of Poet Laureate Nattinger's limericks and Admiral AQ's sea songs

***EDIT: Cross posted invitation to Breakpoint: http://forums.ni.com/t5/BreakPoint/Hope-to-meet-you-at-LAVA-BBQ-during-NIWeek-2012/m-p/1994967/highlight/true#M19185 ***

Uhmmm call me stupid but how do you want to support U64/I64 when the variable size is 1 to 8 bytes you can only support till U32/I32 and not I64 or U64, so my opinion would again be don't support U64/I64.

Well, I won't call you stupid, but a 64-bit integer has no prob squeezing into a size 8 ("hey! who's calling me a bigint??").

It would require a lot of effort to move all content. Any volunteers?

Any interest in using CrowdTilt or similar to raise funds to contract out the migration? I would chip in.

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?

I have used both Bitbucket and Kiln, and could recommend either for Hg hosting. Take a look at both their feature sets, and see which makes more sense for you (e.g., is this for personal use? how many people will share the repo? do you need to allow public access to the repo?) And all-day all-night, I would recommend either these services over "a remote directory out there in the 'cloud' ".

If you're just looking to "scratch your creative itch" for personal learning or recreational programming, I would recommend getting into the LabVIEW Beta program. Benefits:

1. They offer no cost licenses that last essentially year round (the license lasts longer than the Beta period) (the only real cost is confidentiality - you can't distribute Beta source code)
   
2. You get to use the coolest new features of LabVIEW
   
3. You get to help out the quality of LabVIEW by generating bug reports
   
4. You get an opportunity to influence LabVIEW features in development
   
5. and best of all, you get access to the Beta Forum, which is about the highest concentration of in-depth LabVIEW knowledge you can find. There are constantly R&D members patrolling and participating there - it's outrageously resourceful (it's almost as good as LAVA )
   

I specify the SQLite binary at only one point in the library, so it should be easy to substitute different compiled code for different operating systems using a single conditional disable structure.

Cool, and also, +1 for using "Names" Name Format on the calls - good style.

Cool! Just a quick couple of gotchas (that got me) prior to running the examples in this library:

• Install OpenG String Library
  
• Use LV 32-bit since 64-bit LV returns Error 12 for the SQLite DLL calls (I wonder if wrapping the SQLite exe rather than DLL would give better platform independence? just thinking aloud)
  

Those two things settled, both examples run like a champ.

By the way, why did you choose [\s\S]? "Match any whitespace or any not-whitespace."

I'm glad you asked. I have not been able to figure out how to make dots match newlines by turning on single-line mode. LabVIEW does not seem to honor this setting - am I doing something wrong?

It's beginning to look like writing your own parser is the smarter choice. It's pretty often that regex gets misused in that kind of circumstance (if I had a dollar for every time someone tried to parse HTML with regex...). Give it some thought and see if you'd come out ahead with a proper parser.

I'm a little confused by this statement - writing a regex is writing my own parser.

When they're needed, they're extremely powerful, but if you have a fixed delimiter, as in this case, then they will always be slower than a token search.

Gotcha! Well, the particular example above is just a subset of what I'm *really* trying to do, (no, "foo" is not the real section header ). If you saw the full parsing requirements, we would agree that a regex with a few submatches syntactically knocks the socks off of a solution with nested token searches.

***EDIT - And after analyzing the problem a little further, the "tokens" are expressions themselves, not static, so slice-and-dicing the string could really get messy! ***