Do you use manually updated typedefs?

[cw77]

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

[Ton Plomp]

I never used it.

The only instance I can see where it has some value is if you use a Non-Strict Typedef as a GUI element and you need to be in control of the UI. However if you are in that position you have made a poor decision.

Ton

[crelf]

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.

[Darin]

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 October 10, 2012 by Darin

[mje]

I honestly can't remember ever using manually updated typedefs. Any time I don't want to have a linked type, I work with an anonymous one.

[MarkCG]

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.

[Darin]

Thanks. That is precisely what I was attempting to describe in my last sentence, my little bomb-proof containers.

[Phillip Brooks]

Pimping my ideas...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-Block-Diagram-design-for-typedefs/idi-p/940093

[asbo]

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 October 30, 2012 by asbo
Fixed post to illustrate irrelevancy...

[cw77]

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

[asbo]

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.

[cw77]

Thanks to everyone for your replies!