Jump to content

Do you use manually updated typedefs?


cw77

Recommended Posts

Hello All:

I'm trying to gauge how often manually updated typdefs are used in LabVIEW. I (we) expect that the vast majority of typedefs used are automatically updating, and I'd like to confirm that.

If you're using a manual typedef, could you please offer some insight as to why the manual management is preferable to automatic management?

Thanks for your help!

-- Chris

NI LabVIEW R&D

Link to comment

I only occasionally use them, and it's to maintain two versions of one component. ie: if I release an API v1.0, then a new version 2.0 that uses a different version of the typedef. Now if I need to go back to fix an issue in v1.0 that requires me to update teh typedef.

It doesn't happen often, and there are plenty of dicussions online already on how version maintenance is difficult in LabVIEW. I think it would be sad if non-automatic updating went away, but I wouldn't be devistated. Especially if that spurred more discussion and ultimately an elegant solution for maintaining encapsulated versions of components.

Link to comment

I have experimented with this option to solve a very annoying problem for me: typedef constant explosion. As we all know and have come to "love", updating a typedef will explode all constants, many of which I shrink since they are used for typing a Bundle by Name. This can have many undesirable side effects. What I tried instead was to unclick the auto update which now breaks the VI. Now when I have updated the TypeDef I can treat the constant like abandoned luggage: move it to a safe location and blow it up. Afterwards I can shrink it and put it back.

It is effective in this case, but I usually stick to wrapper SubVIs, continuing the luggage analogy these are my bomb proof containers.

Edited by Darin
Link to comment

Hi Darin, one little trick to get get around the typedef explosion is to wrap that constant in a subVI- new VI, drop the constant on the block diagram, create and wire it to an output. Make the VI icon look like a cluster constant or whatever you want. The typedef constant can remain in its exploded state and you can drop that subVI wherever you want.

Link to comment

I have use "bomb-proof containers" quite a bit with typedefs in general, especially with external DLL calls where the struct might need some initialization. I've also used non-auto-update disconnected typedefs to implement backward compatibility with file formats before, which would be a lot more painful (save, rename, replace) if the feature was removed.

Edited by asbo
Fixed post to illustrate irrelevancy...
Link to comment
  • 2 weeks later...

Thank you all for the comments.

I only occasionally use them, and it's to maintain two versions of one component. ie: if I release an API v1.0, then a new version 2.0 that uses a different version of the typedef. Now if I need to go back to fix an issue in v1.0 that requires me to update teh typedef.

It doesn't happen often, and there are plenty of dicussions online already on how version maintenance is difficult in LabVIEW. I think it would be sad if non-automatic updating went away, but I wouldn't be devistated. Especially if that spurred more discussion and ultimately an elegant solution for maintaining encapsulated versions of components.

crelf: I don't think I understand the scenario you're describing. In this case, API 2.0 has updated a .ctl file that API 1.0 also uses, which means that API 1.0 will be broken when loaded into memory unless its references are automatically updating or disconnected. Is that what you're describing? That seems like automatic mode is helping you in that case.

I have use "bomb-proof containers" quite a bit with typedefs in general, especially with external DLL calls where the struct might need some initialization. I've also used non-auto-update typedefs to implement backward compatibility with file formats before, which would be a lot more painful (save, rename, replace) if the feature was removed.

asbo: This is another scenario I don't understand :) If the typedef reference is manual, then it will break when the typedef type changes. If it is disconnected, then it seems more useful for backwards compatibility. Were you perhaps thinking of disconnected instead of manually-updated?

Thanks again!

-- Chris

Link to comment

asbo: This is another scenario I don't understand :) If the typedef reference is manual, then it will break when the typedef type changes. If it is disconnected, then it seems more useful for backwards compatibility. Were you perhaps thinking of disconnected instead of manually-updated?

You are absolutely right, I'm thinking of disconnected typedefs. Please leave me to my madness.

Link to comment
  • 4 weeks 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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.