Community Nugget 5-Mar-2007

[shoneill]

I've just had an "AHA!" moment and a "DOH!" moment at the same time.

Ben wrote: "The type def that was wrapped up is nice and neat. Meanwhile the cluster constant I did not wrap-up EXPLODED!"

NOW I get why people wrap a single constant into a sub-vi.  I always had a bit of trouble getting my head around this, but ben's picture spoke the proverbial thousand words.  But this DOES increase the number of VIs in a project by the number of type-defs used, no?

Shane.

[tst]

---

@shoneill wrote:

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.

[shoneill]

Tst,

That's a great idea.  Viewing constants as icons in general is a great idea.

Someone want to fill out a product suggestion form?

Shane.

[Ben]

"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.

Ben

[waldemar.hersacher]

Ben,

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.

[l1k]

OK, I've never used Typedef, and I didn't really follow everything in this thread.  I just posted this question separately, and the response was to use TypeDef (but no real explaination).  I'm attaching a code in which I've made a cluster, and I'd like to be able to have the control to plot whatever array (in the cluster) I want, without having to add another case to my case structure each time (and subsequently another item on my ring).  Basically, a control on the front panel that would "Select Item" (as I do when I use Unbundle by Name).  I've theorized there must be some option in the Property Node of the cluster I'm missing.  If anyone has time to lead me in the right direction, I would appreciate it a lot.  Thanks!

[Ben]

Hi I1k,

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.

Ben

Message Edited by Ben on 03-07-2007 08:16 AM

[parthabe]

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

Regards,

[tst]

This doesn't work properly for a ring because of the basic thing that makes enums different from rings -

• In an enum, the strings are part of the data type, so you can (for example) wire the enum into a case structure and get the enum elements as the case selectors. This happens because the enum can only be updated at edit time. This is also the reason why when you change a typedef enum all its instances are updated.
• A ring's data type is only its numeric representation, not the strings and values. These can be controlled dynamically and are specific per instance, which is why they're not being updated when you update the typedef. Making the ring a strict typedef means that you can't change most of its properties per-instance, and this includes the list of strings and values, which is why it works after changing it.

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).

[Ben]

HI Partha,

tst gave you the answer. The only thing I would like to add is if you use the technique he mentioned in

"

This week's nugget: Using the context help window to see the data type of a wire.

"

... 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.

Ben