Darren

Multiple people have requested I post the limericks I recited at the BBQ this week. Here they are, as best as I can recall from memory: There once was a coder named Kring He sure liked to right-click on things He once claimed he was faster Than the coding challenge master Yet he’d never step into the ring! There once was a coder named Mercer Who always had a class on his cursor Then Christina stopped by With her eyes on his VIs And said, “Clusters would make this code worser!” There once was a coder named Aivaliotis Who had a cool blog that he showed us It’s called VI Shots And we all love it lots But on facebook he keeps trying to poke us! There once was a coder named Goeres Who spent all his money on... ... ... There once was a coder named Justin Whose popcorn machine kept on bustin’ The problem, he knew, Was in no way LabVIEW Turns out, the real wires were rustin’. There once was a coder named Norm Who made writing VIs an art form. But not akin to Van Gogh, Or Michaelangelo, More like, a 5-year old with Colorforms. There once was a coder named Relf Who was always promoting himself. If only he knew “Image Acquisition and Processing with LabVIEW” to this day gathers dust on my shelf.

I've never tried it in a built EXE, so you'll need to test it. Let me know what you figure out.

Check out [LabVIEW]\help\_exfinder.llb\get NI shared folder path.vi. It's password-protected (makes a callback into LabVIEW.exe), but it does the job.

Whose reputation exactly?

The "Get VI Version" App method will do this without having to load the VI into memory:

I've never seen that. I'd replace the Event Structure if I were you. There may be other corruptions lurking...

I can't speak for the motivation of the certification department, but the stated prerequisite is accurate...you must pass the CLAD before you can take the CLD, and you must pass the CLD before you can take the CLA.

(LAVA ate my previous post, and I don't quite remember all of what I said...here's the short version) Diagram Cleanup does what it's supposed to do on small, lightly-nested VIs, which should make up the bulk of the VIs in your application if it's sufficiently modular. On large and/or heavily-nested diagrams, it should not be used. Check out the whole story of my feelings on block diagram cleanup in this blog post.

I too have been unable to resolve my conflict with the Resolve Conflicts dialog. So yes, vilify away.

It's been a while since high school English, but with that corrective symbol, wouldn't the result be "Wierd" instead of "Wired", which I think is the intent? Here's an idea: could the switcheroo tool somehow be incorporated in the image for switching the letters around?

It seems to me that diagram cleanup is the scapegoat in this situation (why isn't it the evil kid who pressed Ctrl-S on code that wasn't his?). The scapegoat could have just as easily been the Delete key, the Backspace key, a case structure wrapped around the code then removed with an empty case showing, etc. etc. Once Ctrl-S is pressed after any of these actions, you're screwed unless you (1) have a readily available backup of your code or (2) are able in a future LabVIEW version to undo after save. Since it's not August 2011 yet, I vote for the readily available backup of your code. The situation you described really sucks, Crystal, but let's not vilify a feature that isn't being forced on the user in any way by LabVIEW itself, but instead was improperly used in a special circumstance.

Looks like I spoke too soon. Based on some beta feedback, and after discussing the issue further in-house, I will not be including these VIs in 2011. Hopefully, we'll see native support for the error terminals on the primitives themselves in a future LabVIEW version (go vote for this idea if you haven't already). For posterity, here are the VIs I *almost* shipped in 2011, zipped up and saved in LV 2010. And of course, there's also the option of using the OpenG Time Tools VIs. -D timing.zip

And if you're looking to use the complex numeric data type instead of keeping the real/imaginary components separate, then use a Re/Im To Complex function instead of a Build Array in hooovahh's instructions above. -D

As things are currently implemented, you must place your VI Analyzer tests in either [LabVIEW]\project\_VI Analyzer\_tests or [LabVIEW Data]\VI Analyzer Tests in order for them to appear in the VI Analyzer UI, or be otherwise usable with the VI Analyzer. -D

There is a method of the Pane class called "Unlock Objects" that will programatically unlock controls on the specified Pane. It is a scripting method (so it's exposed in LabVIEW 2010, but not earlier versions). Here is a VI saved in 8.5 that has the method so you can use it. Good luck, -D Unlock Objects Method.vi

I was able to unlock the control by following these steps in LabVIEW 8.5: 1. Double-click the "unlockable control" terminal on the diagram to highlight the control on the FP. 2. Drag a selection box around the control (as Chris suggested). 3. Go to the menu and choose "Unlock" from the Reorder pull-down menu. -D

It's all about what you're used to. I've spent my entire life in central and south Texas. I have no clue how to drive a vehicle when the roads are icy, and I don't even try. And I'm not afraid to admit it. ...but then again, I can also spend the entire day outside in July when it's 105 and not drop dead. We all have our strengths and weaknesses. -D

I added VI wrappers with error terminals for Wait (ms), Wait Until Next ms Multiple, and Tick Count in LV 2011. Look for them in vi.lib\Utility\timing. They're not the ideal solution, but until we get error terminals on the primitives, at least we can stop having to worry about maintaining our own copies. -D

Me. Whenever I want a new LabVIEW feature, I just walk over to some C-Monkey's desk and ask him for it.

I just tried a simple use case on my machine and it worked fine. I saved a VI in LabVIEW 8.6. I ran the VI Analyzer on that VI in 2010. I saved the .rsl file next to the VI. I opened 8.6 and loaded the .rsl file, and was able to highlight failure results without errors. Do you have the VI Analyzer Toolkit installed in both LabVIEWs? Are you highlighting test results for tests that are present in both versions (some tests were added in 2009 and 2010)? Are you keeping the .rsl file in the same place? The .rsl file stores VI paths relative to itself, so the .rsl file shouldn't move after you save it. That's all I can think of...if you're still having problems, can you zip up a really simple example that illustrates the problem and I can investigate it further? -D

That looks shopped. I can tell from the pixels. Plus, I've seen lots of shops in my day.

It's also the Windows username of one of our marketing managers. So I'm going with 'coincidence' on this one. But of course, that's probably what y'all expect me to say.

The Get VI Dependencies method (which replaced Callees as the preferred way to get a VI's hierarchy info) seems to work inside an EXE for me: -D

Here's a VI that will give you the path to your LabVIEW INI file. Works on all desktop platforms in LabVIEW 8.0 and later. -D LabVIEW Preferences File Path.vi