Darren

I would like to write a code, what is able to find the ProgramFiles\National Instruments\Shared - Folder...

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.

...such an online reputation to protect.

Whose reputation exactly?

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

Anybody seen this?

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

I would like to get the CLD, but since my employer sees absolutely no benefit to having me certified I'll be doing it all on my own nickel, not to mention taking vacation time off work to take the exam. But after a bit of research I've discovered that getting the CLAD is listed as a prerequisite for the CLD. Is this really the case in practice?? If so, any idea why?? I can't believe it's just money-grubbing on NI's part (and I'm not being sarcastic). If I can pass the CLD, what's the point of the CLAD?

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.

I vilify Clean Up Diagram because it deserves it. How do you "improperly use" a button? There was nothing even remotely "clean" in what it produced; I can't imagine ANY LV programmer wanting their code to look like that. If someone hit Delete, then the *situation* would suck because that's what Delete is supposed to do and you might have clicked it when you didn't mean to. As it stands, I think the Cleanup feature sucks because it doesn't do what it is supposed to.

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

The Resolve Confict dialog(s) are forced upon me occasionally when I move stuff around intentionally. That feature upsets me so much I have to go get a cup of coffee after 1-10 minutes of arrow-enter . Can we vilify that feature?

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

I'm sure you're probably sick of hearing the whole "You only got an inch and had 200 accidents! We have XXX feet and I was fine."

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

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

You'll never guess what I found...

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

Yeah, that user name is me. Coincidence or evidence? You tell me...

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

I just did a search...those methods are not used anywhere (including the Property Pages) in LabVIEW 2010.

I have an educated guess as to their purpose, though. Back when the Property Pages were first added to LabVIEW in version 7.0, there were many properties of VI objects that were not yet exposed in VI Server. As a result, the Get/Set Object methods were added, and hard-coded indices to an internal database of properties were used for getting/setting properties of controls. As the VI Server interface to objects improved, this mechanism was no longer needed, as evidenced by the fact that the Property Pages now (in LabVIEW 2010) rely entirely on VI Server to get/set object properties.

-D

Versions 1.0 and 1.0.1 of the Report Generation Toolkit did not include any logic for attempting to keep other windows open. This logic was added in version 1.1:

Version 1.0.1 of Excel_Quit.vi

Version 1.1 of Excel_Quit.vi

According to this webpage, you can use up to version 1.1.2 with LabVIEW 7.1. I'm not sure if it's a free upgrade or not, so you should probably check with your NI salesperson.

Good luck,

-D

...Or implement something like that in response to all possible events that could change what is displayed.

I've gone down that path before...it's fraught with peril. Example: Grab the scrollbar (mouse down), move your mouse out of the tree bounds (mouse leave), and with your finger still down, drag the scrollbar up and down. All of a sudden, you're not getting events anymore, even though the displayed items are changing. That's why polling is the simplest solution for now...unless you want to implement your own scrollbars.

-D