Jump to content

Refresh Palettes for All Installed LabVIEW versions


Zou

Recommended Posts

Refresh Palette.png

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?

 

Link to post

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 post

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/

Link to post

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 post

> 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 post
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 post
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 post

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.

  • Similar Content

    • By Steen Schmidt
      Hi.
      I have this 'Error & Warning' toolset with a functions and a controls palette:

      The controls palette contains only a single control, basically a subVI dropping its contents on the front panel when dragged there. That contents is two error clusters so I don't have to visit the control palette twice to get those (there are a small number of additional changes to these controls, mainly label and caption formatting to match GPower style). When dragged and dropped I have this on the FP:

      When dropping these it'd be nice if some additional stuff happened, like they automatically got wired to the correct connectors on the conpane (if they are available), maybe they placed themselves more conveniently than where you just happened to drop them etc. Now, I have been wrecking my brain about how to do make them do this. If I turn them into XControls it could probably be done, but I'd hate to turn something as fundamental as the error cluster into a proprietary XControl and litter those all over my (and other people's) VIs.
      I can't seem to get anywere with scripting on this one - the VI isn't being run when it spills its contents when dragged from the palette.
      Do you have any ideas, or is this too much work? I could maybe register some internal LV app event when the 'Error & Warning' toolset gets installed (it's a VIP), but that seems like a lot of work.
      Cheers,
      Steen
    • By David_L
      Hey all,
      As you may know in order to have a toolkit placed on the LabVIEW Tools Network it has to pass Compatible With LabVIEW certification. One of the requirements for the Compatible With LabVIEW program is that tools may not be located on the top palette, but should exist within one of the existing top-level categories such as Programming, Measurement I/O, Data Communication, etc.
      The reason behind this requirement is that the LabVIEW Palette can get quite bloated when you have many toolkits/modules installed. With just the full Developer Suite installed, there are over 20 top level palettes. Adding third party tools to this list will very easily bring the functions palette to grow off of the screen for a standard 1024x768 monitor. The secondary reason behind this is that this layout will help users find the functions more easy that will help them. For example if the user is looking for some data communication protocol, they are more likely to look in the "Data Communication" palette then in a sub-palette called "My Data Protocol" under a top level "DavidSoft Inc".
      I wanted to point this out so as you all start creating their toolkit for submission to Team LAVA or the LabVIEW Tools Network, you can take this into consideration ahead of time. However, with many things in our program, nothing is black and white. If there are special cases in which a toolkit especially should be on the top level, we will consider letting it go as such. One of these cases is OpenG. Since OpenG has a long-standing reputation and is known to be found on the Top level, it would be more hurtful than beneficial to require it moved to the Programming palette.
      If anyone has suggestions or ideas of other corner cases that would benefit from this top level location, or have comments or opinions for or against this policy, please feel free to bring them up here for debate/discussion.
      --David Out
    • By klessm1
      Has anyone see this and know why it occurs?
      Using LV2010.
      Tried the menu's in the lvlib and the lvclass.
      The examples show up ok (assuming because they are outside the library).
      Default palette set for the lvclass to dir.mnu.
      The vi's drop out of the palette ok...they just have the X on them.
      I am using the lvlib because I am giving the option to build a packed library. It is really slow and hogs a bunch of memory in the development environment though when I am working with it so I just went to a source distribution. Might try 2011 to see if they optomized it.
      Thanks


×
×
  • Create New...

Important Information

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