cw77

Thanks to everyone for your replies!

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

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

This was reported to R&D (# 192207) for further investigation. Thanks for the feedback!