Jim Kring

I agree with Adnan. Use the Value Changed event for this.

I think that you wouldn't want to close the process reference in the "spawning" VI, since this could kill the process (since Auto Dispose == TRUE). What I usually do, is pass the reference to the spawned process (via Set Control Value) and let the process (explicitly) close its own reference.

You could create a "wrapper" VI for the CBRN that you invoke using the run method. Make the wrapper VI reentrant and pass 0x08 (prepare for reentrant run) to the "options" input of Open VI Reference, when you open the wrapper, to allow multiple instances of the wrapper (and therefor multiple plugins) to be spawned. Make sure to set Auto Dispose Refnum to TRUE, so that the lifetime of the wrapper is decoupled from the VI that spawns it.

As Jean-Pierre mentioned, VI Server knows whether a VI reference was opened strict, and it uses this to know whether you can or cannot use a CBRN to invoke the VI. What I suggest that you do, is open two seperate references: one strict, and one non-strict. Use the strict reference, only for validating that the VI's con-pane is correct (matching your plug-in conventions). Use the non-strict reference to invoke the Run method. Make sure that both references are opened before closing the strict reference, or you may incur the overhead of loading the plug-in VI into memory twice. BTW, why are you not using the CBRN to invoke the plugins? If you are enforcing a strict con-pane adherance of plug-ins, then this might be the best approach.

it could be a problem with your terminal block. they sometimes go bad.

Thanks for testing this. It's too bad that it didn't work.

You might try installing TortoiseSVN with the .Net Hack option, which can be selected during installation and causes the .svn folders to be named as _svn instead. This might (I have not tested it), cause the mass compile utility to ignore the _svn folders -- there are several instances where LabVIEW ignores folders and files whose names begin with an underscore.

Even if there wasn't, now's a great time to start one

We are looking into it. A transfer of the site to a new server has given us some grief and we have not yet been able to resolve this issue. Thank you for your understanding.

Assuming that any of my questions are serious is a huge mistake. And, if you think about it, there was a Smily in my post.

Hey, Pat: you look very familiar (). Have we met?

And, if you want a pure number (without physical units) in your application, just drop a Convert Units node downstream of the conversion VI that I posted.

First write the units string to the Numeric's UnitLabel.Text property. Then write the value (as a string) to the Numeric's NumericText.Text property. Make sure to write the properties it in exactly that order, otherwise you will might write the value in the '"previous" units and then convert to different units. This technique is very nice, because it will generate an "incompatible units" error, if you try to write to units that are not known or of different base units. Download File:post-17-1140297695.vi

kjimcarrey: Try zipping up your attachments into a single file. This will make it easier for others to download and help you.

zlib compression has been around for years. It's about time.

Yes, I have used it in non-trivial applications. Scripting exists. Scripting works. Scripting makes scripting. The only way (right now) to take away scripting is to make scripting not work. But, NI needs scripting to work, since NI uses scripting. So, scripting will remain. The only way to kill so-called *unauthorized* scripting is to fix significant problems in LabVIEW security, which is a tradoff that I will gladly accept once it arrives, and I will send NI my most sincere thanks and appreciation. We are already seeing some security improvements with Project Libraries in LabVIEW 8.0. Cheers,

Text merge is easy. LabVIEW merge is very hard. Don't expect it to come from NI, unless they will make money off of the feature.

Feel free to write a LabVIEW merge tool and post it here, once it's ready.

TiTou: Well, I did cross-post this question to the LabVIEW forum on the developer zone. There are a lot of beginners there, who might only have a copy of LabVIEW 8.0. Uwe: Personally, I am probably going to wait for the 8.0.1 bugfix. However, I am just one guy -- take a look at this poll to see what others are thinking about migrating to LabVIEW 8.0.

VI Scripting - Readme First

This would be a good item for a LabVIEW Trivia forum. :-)

In LabVIEW 8.0 there is an object traversal routine here: vi.lib\Utility\traverseref.llb\TRef Traverse for References.vi

The poll is now closed. Thank you to all who voted and for your feedback. The winners: Functional Globals Uninitialized Shift Register (USR) Globals :thumbup:

The poll is now closed. Thank you to all who voted and for your feedback.

I'm wondering what version of LabVIEW most people are using for new projects -- not existing projects, but ones started from scratch.