Jump to content

Refresh Palettes for All Installed LabVIEW versions


Zou

Recommended Posts

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.

Link to comment

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.

 

  • Like 2
Link to comment

> 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

 

Link to comment
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.

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.