03-08-2007 07:53 AM
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.
07-11-2007 04:45 AM
Dear LabVIEW specialists,
regarding 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.
I recently discussed these problems within this forum and only was told that this is a known behaviour of LabVIEW.
In my 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 do.
(i.e.
If the answer is "NO" the following question would be whether a compiler
not supporting type definitions can be called a compiler?
Best regards,
Michael
07-11-2007 07:37 AM
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)
Please clarify.
Just trying to help,
Ben
07-11-2007 08:11 AM
Dear Ben,
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).
Best regards
Jens
07-11-2007 08:32 AM
07-11-2007 10:34 AM
Hi Jens/Michael,
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.
Thank you,
Ben
08-29-2007 12:38 PM
Ben,
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.
Tammo
08-29-2007 12:53 PM
Tammo wrote
"Thank you very much for your nuggest. It is greatly appreciated."
You are welcome Tammo. Posts like yours motivate me to "keep em cooking".
Thank you!
Ben
09-11-2007 09:24 AM
Are you cooking yet another nugget, Ben??
🙂
09-11-2007 10:21 AM
Are you cooking yet another nugget, Ben??