Jump to content
News about the LabVIEW Wiki! Read more... ×
hugo_fr

LabVIEW Shell Launcher

Recommended Posts

this is a great tool!

I managed to launch 7.0, 7.1, 8.0, 8.6 and 2009 at once.

ton

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Hi Hugo,

Nice tool! I have done some work on a similar function for my department but I bottled out a bit on proper right-click integration and just put a shortcut in the send to... menu. What did you find the best way of customising the right click menu was?

Cheers,

James

Share this post


Link to post
Share on other sites

Here is the same tool compiled with LabVIEW 2014 SP1.

 

LabVIEW Shell Launcher 1.0.8

 

Does anyone have an idea how to determine the difference between VIs saved with a LabVIEW 32-bits and a LabVIEW 64-bits ?

 

Hugo.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Could we have an option to skip the bitness dialog ?

Maybe in the ini file, set to open only in 32 bit?

 

Most of time, I only need to take a look a VI.

Don't care if it was compiled in 32bit or 64bit.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

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