Variant Data Type Package

[jgcode]

Hi Guys

Attached is a package that installs a palette in user.lib to expose the Variant Data Type API found in vi.lib\Utilities\VariantDataType.

Enjoy

-JG

jgcode_fix_ni_variant_data_type-1.5-1.ogp

[LabVIEW 8.2+]

[Daklu]

Thanks Jon. Exposing non-standard features using VIPM is very helpful.

Note to users: NI's policy is that vis in vi.lib are not for public use unless they are on the default palettes. Functionality is subject to change in future versions and forward compatibility is not guaranteed or implied. This isn't to discourage anyone from using them, just be aware of the potential consequences.

[jgcode]

Thanks Jon. Exposing non-standard features using VIPM is very helpful.

Note to users: NI's policy is that vis in vi.lib are not for public use unless they are on the default palettes. Functionality is subject to change in future versions and forward compatibility is not guaranteed or implied. This isn't to discourage anyone from using them, just be aware of the potential consequences.

Good point - although I thought that was what the resource folder was for

I have been digging into this API more and more with scripting etc...

So I didn't want to keep doing this from disk.

[jzoller]

This is a really nice convenience, thanks!

Joe Z.

[Francois Normandin]

Good point - although I thought that was what the resource folder was for

I have been digging into this API more and more with scripting etc...

So I didn't want to keep doing this from disk.

You can limit your responsability by making the package to be installed on version = 9.0 instead of >=9.0...

But then, you'd have to make a new package for 10.0 after you've verified the compatibility, and 11.0... and 12.0.

I suggest you wait until it breaks.

[jgcode]

This is a really nice convenience, thanks!

Joe Z.

No probs!

You can limit your responsability by making the package to be installed on version = 9.0 instead of >=9.0...

But then, you'd have to make a new package for 10.0 after you've verified the compatibility, and 11.0... and 12.0.

I suggest you wait until it breaks.

I did look that this originally, but yer, its not really maintainable for me, so v1.0.5 is all opened up.

[crelf]

You can limit your responsability by making the package to be installed on version = 9.0 instead of >=9.0... But then, you'd have to make a new package for 10.0 after you've verified the compatibility, and 11.0... and 12.0. I suggest you wait until it breaks.

You wouldn't have to make a totally new package - once the functionality is confirmed in the new version, then you'd just need to update the old package to support the new version, right? Does VIPM allow selection of different versions? Say, 2009 and 2010 only?

[jgcode]

You wouldn't have to make a totally new package - once the functionality is confirmed in the new version, then you'd just need to update the old package to support the new version, right?

I took François to mean that i.e. new version of the same package (therefore, new package).

Does VIPM allow selection of different versions? Say, 2009 and 2010 only?

This is an example of the options:

[Francois Normandin]

You wouldn't have to make a totally new package - once the functionality is confirmed in the new version, then you'd just need to update the old package to support the new version, right? Does VIPM allow selection of different versions? Say, 2009 and 2010 only?

Like Jon said.

Of course, vip files are not editable using text editor due to checksum, but an opg file certainly would be updatable easily for newer versions... Not that I would do that: it would be faster to simply change the install requirements and repackage it as you suggest.

[jgcode]

Like Jon said.

Of course, vip files are not editable using text editor due to checksum, but an opg file certainly would be updatable easily for newer versions... Not that I would do that: it would be faster to simply change the install requirements and repackage it as you suggest.

As a side note we did that on the OpenG 4.x release to e.g. update a link to the new palette folder in some.ogp files.

It worked just fine (and we had to do it this way rather than repackage for some other reasons).

[crelf]

I took François to mean that i.e. new version of the same package (therefore, new package).

Sorry, I didn't mean editing the existing package, I meant rebuilding it and deprecating the previous. A previous post looked like there would be 2 packges both being supported simultaneously. I think we're all on the same page now.

[Ton Plomp]

You can limit your responsability by making the package to be installed on version = 9.0 instead of >=9.0...

But then, you'd have to make a new package for 10.0 after you've verified the compatibility, and 11.0... and 12.0.

I suggest you wait until it breaks.

How would this resolve (or just limit your responsability)?

A user wouldn't be able to select the broken VI, however old code will still have the new broken VI.

I don't see this as a solution.

Ton

[Francois Normandin]

That's a very old thread... I'm not sure I remember why I wrote my answer like that. Of course, you're right that it is not a viable solution to use code that could break later.

I think I meant that if you make your package "version = 9.0", then you will not be able to install it on other LV versions using VIPM. In essence, you would not be able to update your code to a new version unless you get rid of all this package's VIs. That will prevent it from breaking in a future LabVIEW version because you cannot use it unless you copy it by yourself instead of using VIPM. But if you do so, you cannot blame the original packager for the break in your code. That's what I think I meant by "limit your responsability": by making it strictly a LV9.0 package.

For the rest, I kind of suggested that it might never break, so the packager could take a chance and just package it for any future versions... That in itself is not good advice (but that seems to have been what I meant at the time) and Chris suggested a better approach would be to incrementally repackage it each year and deprecate the old package. I agree with that.