Conditional Disable LabVIEW Run-Time Versions

[Hooovahh]

Right now we can make a conditional disable structure that behaves one way if we the VI is running in the Run-Time engine or not.  What I think would be useful is if we could also decide on performing one case or another based on the version of the Run-Time/Development of LabVIEW.

Say I develop some neat little reuse VI that relies on getting the name of the label of data type passed in.  OpenG has a functional already that does this called Get Data Name.  NI has a version as well in vi.lib called GetTypeInfo.vi.  The problem is in 2011 the OpenG method is about 10 times faster, but in the 2013 version the NI version is 10 times faster.

Wouldn't it be nice if a conditional disable structure could choose to do one thing over another, based on the version of LabVIEW it was being run in?  This way reuse code could be written to perform best in what ever version it was running in.

There are many situations were one code written using some function either runs slower or faster in different versions of LabVIEW and using this we could choose the best option for that environment.

Of course there is a work around and that is to read the App.VersionYear property, put that into a case statement and perform different code for one version or another but this has added over head, and is called every time it is needed.

EDIT: Also the App.VersionYear can't be used in inlined VIs because it is a property node which a conditional disable can be used.

[crossrulz]

I have to admit, I am a little torn on this.  I can see the benefit for some reuse code, but there are other ways to get around this with tools in VIPM.

[Hooovahh]

I do love using VIPM to get around issues with reuse deployment.  How would you suggest doing it?  Having two packages one for 2011 Only and one for 2013?  What about how to handle dependencies?  What if a package relied on that package?  Would I make it a dependent on the 2011? or 2013?

One option is on Post-Install of a package I could edit a VI that was just installed to have a string constant which is LabVIEW version, causing one set of code to be called instead of another.  Is that too hacky?

[crossrulz]

I was thinking setting a package version to be good for up to 2011, while another version of the same package for 2013.  Yes, it is a pain.  But quite doable.

I did give your idea a Kudos, because it would make the reuse library easier to maintain.  I just wish I could come up with another scenario where this would be useful.

[Hooovahh]

In some versions of LabVIEW the fastest way to detect a string has a substring is the Search/Split, some times it is Search and Replace String.  In some versions the conditional index is quite good, in the first iteration it wasn't the best because it was essentially a build array, so maybe preallocating, then replacing and then array subset would be the most efficient way to perform the task.

I can think of a few more, and likely in the future one version of LabVIEW will do some task in a slightly different way and be a more prefered solution.  I don't know how often it would be used but I have a few uses for it right now.

[crossrulz]

Apparently I needed to clarify myself some more.  I wish I could come up with another scenario other than managing a reuse library where this could be useful.

[drjdpowell]

Reuse libraries are important.  And conditional disables are a lot easier than multiple versions.   I'm the one with the issue that motivated Hooovahh's posting of this idea.  Conditional Disables are easy and I would happily do that.  Maintaining multiple versions sounds annoying and I'm unlikely to do that.

-- James

[kegghead]

I agree with James. Plus VIPM is not the only way to manage re-use libraries, invoking it to address the problem doesn't seem like a solution to me. This is something that could easily be managed by the core language grammar.

[AristosQueue (NI)]

I fully support this idea. I have wished for it many times.

[AristosQueue (NI)]

One important comment. The original idea says:

>based on the version of LabVIEW it was being run in

No... that needs to say, "based on the version of LabVIEW it is INTENDED to run in."

When you build a distribution, you would have to specify as part of your compile which frame to compile in since there is no compiler in the runtime engine.

(If you want to do runtime selection of which code to run, you already have that today by querying the Application property for the LabVIEW version and using a Case Structure to run the appropriate code. Regarding this comment "Also the App.VersionYear can't be used in inlined VIs because it is a property node which a conditional disable can be used.", you can call the property at a higher level and wire it into the inlined subVI. That's more appropriate behavior for run-time deciding code anyway since the property only gets read once and passed to all functions that need it.)

[Hooovahh]

@AQ

I'm generally talking about VIs and haven't fully thought about how to handle a compile.  If I'm developing code and call a VI that has one of these, then build an EXE it will include the version for that run-time, which is the same as the version I was developing in.  Other distributions would need more thought for sure.

Regarding the App.VersionYear suggestion.  I have a reuse component that say performs a search 1D array and returns an array of indicies not just the first.  Say in 2012 one method is much faster, and in 2013 a different one is.  I don't want to call App.VersionYear in the reuse component because that means it can't be inlined, and there is unneccesary overhead from a call that will return the same value for this run.  I also think it would be crazy for my Main VI to have to pass in the App.VersionYear into this search 1D array function.  At the moment I have a string constant that, on post install of the reuse package it will write the App.VersionYear value.  Of course it uses the default case if for some reason the post install didn't work.