Jump to content
jgcode

Variant Data Type Package

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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 biggrin.gif

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

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

Share this post


Link to post
Share on other sites

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

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. ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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:

post-10325-0-37199400-1313963804_thumb.p

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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. wink.gif

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.