03-06-2007 02:16 AM
03-06-2007 04:36 AM
NOW I get why people wrap a single constant into a sub-vi. ... But this DOES increase the number of VIs in a project by the number of type-defs used, no?
Yes, and that's the main annoyance about it, since you have to handle the extra overhead (VI, Icon, Documentation) for almost every typedef.
So, here's the wishlist item - how about being able to right click typedef constants and select "View as Icon"?
This would be the same as having the cluster as a control on the FP and selecting the icon option (it shows the typedef icon), but would not require handling the extra control (moving, hiding, etc.) for each VI where we want to have this and would not require creating the extra VI. Obviously, LV will need to remember this option for each constant and not revert it when we update the typedef.
Partha, CC went on one of his vacations, but he should be back now.
03-06-2007 04:57 AM
03-06-2007 06:08 AM
"So, here's the wishlist item - how about being able to right click typedef constants and select "View as Icon"? "
GREAT IDEA tst!
And if the help from the type def showed up when you float over it, even better.
03-06-2007 09:38 AM
very nice description. I'm doing it this way at least the last 4 Years.
Typedefs are created most of the time at first when I start to program a new module. I'm creating the SubVIs for defining constant values and saving place on the BD. Saving time I copy the icon from the typedef to the SubVI and change only the background color. The naming of the SubVI follows the scheme to add Const as a postfix to the file name of the typedef. For clusters only Bundle by Name and Unbundle by Name are allowed. And never change the cluster order. This way I never had any troubles adding new data to any data structure.
03-06-2007 09:50 AM
03-07-2007 08:15 AM - edited 03-07-2007 08:15 AM
I think you are trying to plot anything vs anything. This could be done using control references and property nodes but this is off topic for this thread.
I'll try to find your other thread if I have time later.
Message Edited by Ben on 03-07-2007 08:16 AM
03-08-2007 12:28 AM
Ben & All,
I ve a serious doubt reg Type Defs for Rings instead of Enums.
After reading thro' this post, and studying in detail the VIs given in Code.zip, I began to do a small modification in my project. It consists of nearly 150 VIs, wherein a Ring Control called Unit is present in some 10 UI FPs. So, I decided to use a Type Def Ctl for this Ring.
I took one of the Rings from one of those FPs & pasted it in a new VI & custtomized it as a Tyoe Def & saved as Unit.ctl. Now, I closed LV & reopened my project from the topmost VI, thro' to the sub-VIs that ve this Unit Ring Ctl. One by one, I began to replace these Unit Ring with the newly created Unit.ctl Type Def.
To my disbelief, they didnt get replaced on the first instance, but only on the second exactly. This repeatedly happened for all the sub-VIs.
To my horror, when I added an item later into the 3rd location of the Type Def Ring Ctl and saved it seperately, and later opened my topmost VI, navigated thro' to the sub-VIs one by one, I found out that none of them had got updated with the New Item I added earlier... !
But, I saw the 'Automatically Update from Type Def' short-cut menu item was checked already ( by default, I think )
Again I ve to Rt Click, Replace each one of them with the modified Type Def.
I thought it may be a general nature of the Type Def made for a Ring. I really went mad...
Then, my colleague suggested me to remake it into a Strictly Type Def Ctl, after playing with it while debugging.
Ah ! It began to work nicely if I edit its items thereafter.
Now, I want t ask the real question. Are Type Defs made to work automatically only for Enums ( Clusters I ve not tried yet ) ? Is it necessary to make it a Strict Type Def for Ring controls for the items to get automatically updated ?
Please clarify me reg this...
Using LV 7.1
03-08-2007 01:36 AM
This doesn't work properly for a ring because of the basic thing that makes enums different from rings -
The key is to understand that a typedef controls the data type (as opposed to value and other properties), which is why a cluster will also update properly (a cluster's structure defines its datatype).
03-08-2007 07:47 AM
tst gave you the answer. The only thing I would like to add is if you use the technique he mentioned in
... for a ring and an enum you will see the enum includes the values as part of the data type.
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.