Refresh Palettes for All Installed LabVIEW versions

[Zou]

I don't want to manually launch all installed LabVIEW versions one by one, and call this method.

Is there a way to do this in one version to refresh palette for all installed versions?

 

[hooovahh]

Well it is possible but a pain.  Is there a minimum version of LabVIEW you want to support?  I think that function came around in 8.2 or so.  What I'd suggest doing is create a VI with just that function in it, and save it in the lowest version of LabVIEW you want to support.  Then ensure each version of LabVIEW installed is configured to use VI Server from localhost (basically make sure VIPM can connect to each version).  Then you can have a VI that opens a connection to each version of LabVIEW installed using the Open Application Reference function, then use the Open VI Reference passing in the path to the VI you saved earlier and using VI Server run it.

I created a tool a while ago that sits in your system tray and allows you to launch any version of LabVIEW installed.  It also allows you to abort all VIs running in all versions of LabVIEW and it uses this technique by having a VI saved in an older version of LabVIEW and embedded in another VI, and then runs this VI in every version of LabVIEW installed.  The source for this can be found here with the topic on LAVA here.

[smithd]

Even without VI server I believe if you go to the command line and type <path>/labview.exe "<mypath>/myVI.vi" it will load the function and run it (if you have the properties set to run when opened):

http://digital.ni.com/public.nsf/allkb/44E99CC41AA39F538625694B005679C0

https://zone.ni.com/reference/en-XX/help/371361J-01/lvdialog/execution/

[hooovahh]

The command line option only works if you know no other versions of LabVIEW are currently open.  LabVIEW communicates over DDE to other versions of LabVIEW, and that is why some times you'll see LabVIEW try to open the wrong VI in the wrong version.  If you double click a VI, or open it over the command line, it may choose to open it in the wrong version even if the command line specified which version to open it with.  Here is a post I made on it a while ago and many other applications (like VIPM launching LabVIEW, and LabVIEW version selection tools) suffer from this issue.  The work around is using the technique I've mentioned.  But if you can ensure no versions of LabVIEW are running, maybe by closing them all, making a VI that runs when opened is much easier.

 

[Zou]

> What I'd suggest doing is create a VI with just that function in it, and save it in the lowest version of LabVIEW you want to support.
> Then you can have a VI that opens a connection to each version of LabVIEW installed using the Open Application Reference function, 

 

Thanks for reply.

That was my plan, but you can't specify the path of LabVIEW.exe when call Open Application Reference. 

 

> Then ensure each version of LabVIEW installed is configured to use VI Server from localhost (basically make sure VIPM can

> connect to each version).

I can't do that on users' computer.

 

I'm creating a reusable VIs/Ctrls package for internal use.  I downconverted all VIs/Ctrls to LV2011, and use VIPM to build a package.

After installed for LabVIEW 2011 (or any later versions), installer will invoke a VI to add a link on the palettes for all other installed LabVIEW versions without open those version one by one.  That seems working fine.

When reusable VIs/Ctrls folders get updated, users just need to sync to a database.  No need to build a new package.

I was plan to use the Refresh Palette to update all installed LabVIEW versions, but neither Open Application Reference nor Refresh Palette support path.

Sync with the folder seem solve the problem.

 

Thanks again.

George

 

[hooovahh]

8 minutes ago, Zou said:

> Then ensure each version of LabVIEW installed is configured to use VI Server from localhost (basically make sure VIPM can

> connect to each version).

I can't do that on users' computer.

If you are using VIPM this is already done for you.  To be able to install a package means that the VI Server business is already working.  As for how to know what port is what version of LabVIEW, you can look at the LabVIEW.ini to see what port goes to which, and you can read the Windows registry to find what versions of LabVIEW are installed, and the path to the LabVIEW.exe and LabVIEW.ini files.  This is all done in the source of the LabVIEW Tray Launcher I linked to earlier.

Glad you were able to find a solution.

[smithd]

13 hours ago, hooovahh said:

The command line option only works if you know no other versions of LabVIEW are currently open.  LabVIEW communicates over DDE to other versions of LabVIEW, and that is why some times you'll see LabVIEW try to open the wrong VI in the wrong version.  If you double click a VI, or open it over the command line, it may choose to open it in the wrong version even if the command line specified which version to open it with.  Here is a post I made on it a while ago and many other applications (like VIPM launching LabVIEW, and LabVIEW version selection tools) suffer from this issue.  The work around is using the technique I've mentioned.  But if you can ensure no versions of LabVIEW are running, maybe by closing them all, making a VI that runs when opened is much easier.

 

Oh thats really annoying, I assumed if you gave it a path to the specific executable you wanted it would work.