Jump to content

LabVIEW Shell Launcher


Recommended Posts

  • 1 month later...

What benefits does this have over this: http://lavag.org/top...w-tray-launcher ? Can the functionalities be merged?

I realize this is a month old but I wasn't able to check Lava consistently recently.

Yeah so my LabVIEW Tray Launcher is different from this application in a couple ways. In my application there is a registry tweak that makes it so that LabVIEW does not get ran when a .VI file is double clicked, but instead my program runs then launches LabVIEW based on what the user selects. This can be a good thing or an unwanted thing based on how you use LabVIEW.

Often I will download a VI from the web and I just want to open it quickly. So I'll choose the Open option in my web browser instead of download. It will download it to a temp directory then open it with my launcher then choose the right version of LabVIEW. This is an interesting case because I don't know the exact location of the saved VI (I could find out easily) and I don't know the version of LabVIEW it was written for. In this case the Shell Launcher wouldn't help because the VI would be opened with the default version of LabVIEW since you would need to right click the VI and choose the option to launch it.

On the other hand some people probably don't want my program taking over the .VI file extension and may want to right click the VI and choose the right one.

My program could be changed to be a right click menu option, and I'm sure that this program could be changed to be ran when double clicking a VI and not just right click.

My program does offer a few other features that might be useful but I'll try not to turn this into a post about my program.

Link to comment
  • 11 months later...

Here is the updated version for LV 2010 SP1 : LabVIEW Shell Launcher 1.0.5.zip

New : Added support for .lvlibp files

-------------------------------------------------

Requirements :

Windows XP or later

LabVIEW 2010 SP1 RunTime Engine (10.0.1)

(available for free at www.ni.com)

Use :

Right Click on a LabVIEW File

Select 'Open with LabVIEW Compatible Version'

Supported file formats :

.vi .vit

.ctl .ctt

.llb .lvlib

.lvproj .lvclass

.xnode .xctl

.lvlibp

Link to comment
  • 2 months later...
  • 4 months later...

The version 1.0.7 detects LabVIEW 32bit/64bit versions distinctly.

If you have both 32 bits and 64 bits of the same LabVIEW versions installed ( 9,10, 11 or more...), it will ask for which version to launch.

Debug : removed install error for some invalid registry keys when only older versions of LabVIEW are installed. (Yes, this can still occur !!)

:lightbulb: If someone know how to distinguish the bitness of a VI, please share it !!! :lightbulb:

Hugo

Link to comment
  • 2 months later...
  • 2 weeks later...
  • 3 years later...

So a VI might not have the bitness in the VI, due to the fact that the bitness is in regards to the compiled code, which might not be int he VI file.

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Property-to-get-LabView-Editor-bitness-32bit-64bit-and-patch/idi-p/2978707

 

That being said I'd suspect this information is available somewhere in the VI as a private function, or the VI file structure itself.

 

But for this tool I don't think it matters, because VIs saved in 64 bit LabVIEW can be opened in 32 bit LabVIEW and vise versa.  So for your tool you can show the compatible version as both the 32 bit and 64 versions installed.  Of course I don't have a 64 bit version installed at the moment to test with.

Link to comment

Yes, the tool already show both 32-bit and 64-bit versions, but the purpose is to launch the appropriate version of LabVIEW when working with multiple simultaneous projects.

 

The fact is that a VI saved with LabVIEW 20xx 32 bits if different from the same VI saved with LabVIEW 20xx 64-bits. (Binary file content)

 

When working on a project requiring a 64bit version, the tool should launch the 64bit version, instead of asking the developer.

Link to comment

To me this seems like a matter of opinion, on how this tool should behave.  If the purpose is to show the various versions of LabVIEW that are compatible with the VI, then I would think it should show both the 32 and 64 bit versions of LabVIEW.  Because after all both are compatible with opening the VI.  But I understand that showing the user the version it was last saved in might be helpful.

 

Well to help out could you post a 32 bit and a 64 bit version of the same VI, and possibly two other versions that have separate compiled code or not.  Looking at the private methods nothing jumps out to me as what you want, but there are some bit options that I can't predict what the values will be for other VIs.  The other option is to look at the VI file structure on a binary level and find the differences.  I suspect there might be something in there but again without any VIs to look at I can't say for sure.  

 

But there is the real possibility that this information just isn't in the VI.  Source might not care what bitness it was saved in, so maybe NI doesn't save that information in the VI, only in the compiled code.

Link to comment

Yeah I opened these in LabVIEW 2015 32-bit and I don't even get prompted to save on close, no dirty dot, no recompile.  I'm not convinced bitness is even saved in the VI.

 

EDIT: Reading the block data the only thing that has changed between the two is the FPHb block, which I doubt has anything to do with bitness.

Link to comment

Yeah I opened these in LabVIEW 2015 32-bit and I don't even get prompted to save on close, no dirty dot, no recompile.  I'm not convinced bitness is even saved in the VI.

 

EDIT: Reading the block data the only thing that has changed between the two is the FPHb block, which I doubt has anything to do with bitness.

 

 

I would guess this is only true if you use compiled code separated from the VI. Otherwise the according binary compiled code resource in the VI will be very much different and definitely will have some indication of bitness. Still for the rest of the VI it most likely indeed doesn't matter at all, especially for an empty VI. There might be certain things on the diagram that change but I would guess almost all of it is code generation related, so would actually only affect the VI itself if you don't use seperate compiled code.

Link to comment
  • 1 month later...
  • 3 weeks later...
  • 2 years later...
  • 5 months later...

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.