Only remember to do this inside the typedef (don't replace the typedef with another one)
Hint: Rings can be replaced with enums and all of the values will be transfered to the enum. If you already have this control type def'd the fix should be easy.
Dear LabVIEW specialists,
the frequently discussed use of type definitions and its advantages I now want
to turn your’s attention to some serious problems that LabVIEW implicates while
using type definitions.
Please see the attached sample programs for closer details.
I recently discussed these problems within this forum and only was told that this is a known behaviour of LabVIEW.
opinion this is unacceptable. Changes on already available type definitions result
in oodles of debug work that the developer (and this certainly means us) has to
The main question is whether a fundamental programming feature as a type definition could be a fundament if it is delivering as many errors as this LabVIEW feature.
If the answer is "NO" the following question would be whether a compiler not supporting type definitions can be called a compiler?
This was discussed in this Nugget along with techniques to avoid this issue.
There was a bug in earlier version of LV that resulted in the wrong element of a "bundle by Name" function being used after a typedef edit. This bug was resolved. (I do not remeber what version)
Just trying to help,
thank you for your responses so far. Here a short statement to the three points stated above:
* cancelling defult values: the Nugget resp. the comments accompanying it suggested to explicitely initialise the front panel elements. This surely is the best way to avoid problems but it tells us not to use the function of storing initial values with front panel elements because it is not working securely... Here is a function ... BUT ... don't use it!
* Mixing of element for named bundle/unbundle: may be it was fixed but not for long. I am sure we saw it under Labview 8.0.
* Mixing program code is another heavy error in this contents as example ClusterInitialDataError-2.llb shows (see examples in the above community messages). In this example the events are exchanged after deleting an element of the cluster typedef. (So an entry to the Enum would deliver a text belonging to the reaction to the array. This in case that the VI would be operable any longer, which it was assumed to be, because the removed element was not used by the event structure).
Could you please start new threads for each of these issues seperately?
You could then update this thread with a link to those posting.
If there is a bug in the typedefs, we want to know about it.
Expanding this thread with a discusion of the issue you are raisine will only limit your readers.
you just saved me A LOT of time. I am currently working on a somewhat dynamic applications where its requirements change rather frequently as new ideas come up. I initially collected all data in a HUGE number of globals, then as I learned more, changed then into one HUGE cluster. The problem I was having with this was, that, if I wired the cluster between the sub-vis, I had to change every single sub-vi if I changed the cluster. I now made the cluster a global and access the global in every sub-vi. It works, but not is still not really elegant. The solution for the type defs is great, and rather elegant. One place to change. Thank you very much for your nuggest. It is greatly appreciated.
"Thank you very much for your nuggest. It is greatly appreciated."
You are welcome Tammo. Posts like yours motivate me to "keep em cooking".
Are you cooking yet another nugget, Ben??