cw77 Posted October 10, 2012 Report Share Posted October 10, 2012 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 Quote Link to comment
Ton Plomp Posted October 10, 2012 Report Share Posted October 10, 2012 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 Quote Link to comment
crelf Posted October 10, 2012 Report Share Posted October 10, 2012 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. Quote Link to comment
Darin Posted October 10, 2012 Report Share Posted October 10, 2012 (edited) 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 Quote Link to comment
mje Posted October 10, 2012 Report Share Posted October 10, 2012 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. Quote Link to comment
MarkCG Posted October 10, 2012 Report Share Posted October 10, 2012 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. Quote Link to comment
Darin Posted October 10, 2012 Report Share Posted October 10, 2012 Thanks. That is precisely what I was attempting to describe in my last sentence, my little bomb-proof containers. Quote Link to comment
Phillip Brooks Posted October 12, 2012 Report Share Posted October 12, 2012 Pimping my ideas... http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-Block-Diagram-design-for-typedefs/idi-p/940093 Quote Link to comment
asbo Posted October 15, 2012 Report Share Posted October 15, 2012 (edited) 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... Quote Link to comment
cw77 Posted October 30, 2012 Author Report Share Posted October 30, 2012 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 Quote Link to comment
asbo Posted October 30, 2012 Report Share Posted October 30, 2012 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. Quote Link to comment
cw77 Posted November 26, 2012 Author Report Share Posted November 26, 2012 Thanks to everyone for your replies! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.