Prevent "Update Type Def" From Updating Layout?

[lvb]

I am looking for some advice in the use of type defs...

Upon selecting the "Update from Type def." option, my screen layout is lost.

1. Is there a way to update the "data" of a type def. and not the screen layout?

I understand that the better solution would be to layout the typedef to match the desired screen layout, but what if I want to use the same typedef in two different layouts on two different front panels?

2. How does everyone deal with updating typedefs if this is the case (lose layout when updating typedef). Is it best practice not to use typdefs for front panel layout? When to use strict

Thanks!

[Tomi Maila]

QUOTE(brianafischer @ Jun 12 2007, 07:15 PM)

1. Is there a way to update the "data" of a type def. and not the screen layout?

I understand that the better solution would be to layout the typedef to match the desired screen layout, but what if I want to use the same typedef in two different layouts on two different front panels?

I guess with "data" you don't mean data values but typedef type? Typedefs don't specify data values. When you change the type, you also change the layout as there is no way to convert one layout to another. For example there is no way to convert layout of an I32 control to a layout of cluster of string array and boolean. So the answer to your question is no, it's not possible. I don't really even understand what you actually expect LabVIEW to do in these situations.

QUOTE(brianafischer @ Jun 12 2007, 07:15 PM)

2.

How does everyone deal with updating typedefs if this is the case (lose layout when updating typedef). Is it best practice not to use typdefs for front panel layout? When to use strict

Use strict typedef when you want to change the typedef look and feel and want that look and feel change to propagate to all controls using that specific typedef. Use non-strict typedef to allow changing the look and feel of each control connected to a typedef but still keeping the type the same. Both typedef and strict-typedef update both the type and the look-and-feel when the type of the typedef is changed as the old look and feel can no more represent the type content of the typedef.

[Grampa_of_Oliva_n_Eden]

QUOTE(brianafischer @ Jun 12 2007, 12:15 PM)

I am looking for some advice in the use of type defs...

Upon selecting the "Update from Type def." option, my screen layout is lost.

...

If you just change the typed def (by editing and saving the ctl) and you skip the "update from type def" step, what happens?

Ben

[Yair]

QUOTE(Ben @ Jun 12 2007, 08:28 PM)

If you just change the typed def (by editing and saving the ctl) and you skip the "update from type def" step, what happens?

I believe LV will load the updated typedef the next time you open the VI.

Tomi, the problem is with having different displays for the same typedef. Changing the typedef causes all instances to be updated with the current look.

I don't think there is any way around this, really, other than not using the typedef for the display.

[Grampa_of_Oliva_n_Eden]

Right-click on the FP instance of the control and slect "disconnect from type def".

If the data type changes, the VI will break and you will either have to edit the control to match the type def or you can replace the obsolete instance with the new typed def.

Ben

[Mellroth]

QUOTE(brianafischer @ Jun 12 2007, 06:15 PM)

I am looking for some advice in the use of type defs...

Upon selecting the "Update from Type def." option, my screen layout is lost.

1. Is there a way to update the "data" of a type def. and not the screen layout?

I understand that the better solution would be to layout the typedef to match the desired screen layout, but what if I want to use the same typedef in two different layouts on two different front panels?

2. How does everyone deal with updating typedefs if this is the case (lose layout when updating typedef). Is it best practice not to use typdefs for front panel layout? When to use strict

Thanks!

Hi

If you want to preserve the layout of the typedef elements within your VIs, I think it is enough to group the cluster elements (in the "right" position).

This should work for changes like default value, positions of elements, coloring, but it wont work if you add/remove elements or if you change cluster order.

/J

[dthomson]

Brian,

Buddy Haun, an Alliance member here in Colorado, and I discussed our similar efforts to solve these types of situations some time ago. He developed some interesting techniques for dealing with this that go beyond what I have done. You should be able to find an e-mail address for him through the Alliance list on ni.com.

The basic idea is to use a hierarchy of type-defs. Use one non-strict type-def to define the type of your data. Then make several strict type-defs that each use the non-strict type-def within them. Each of these strict type defs can have a different appearance. When you alter the root type-def, you'll need to update all your strict type-defs, but those will be the only edits. All the instances in all your VI's will then be updated as you desire. Using this technique, you can display the same data cluster in multiple places, but hide certain elements from the user depending on the context.

Cheers,

Dave T.

[lvb]

QUOTE(dthomson @ Jun 12 2007, 05:11 PM)

Brian,

Buddy Haun, an Alliance member here in Colorado, and I discussed our similar efforts to solve these types of situations some time ago. He developed some interesting techniques for dealing with this that go beyond what I have done. You should be able to find an e-mail address for him through the Alliance list on ni.com.

The basic idea is to use a hierarchy of type-defs. Use one non-strict type-def to define the type of your data. Then make several strict type-defs that each use the non-strict type-def within them. Each of these strict type defs can have a different appearance. When you alter the root type-def, you'll need to update all your strict type-defs, but those will be the only edits. All the instances in all your VI's will then be updated as you desire. Using this technique, you can display the same data cluster in multiple places, but hide certain elements from the user depending on the context.

Cheers,

Dave T.

Interesting! This sounds like a great idea. The main reason I started this thread was to find "solutions/work-arounds" of this manner. Do you have any examples?

-Brian

[Yair]

I think the point is basically as shown in the attached VI.

You divide the parts of the data into seperate typedefs and create caller typedefs for each of your displays. Each of the caller typedefs can display a different combination of the sub-typedefs. I don't think this really solves your problem, because modifying a sub-typedef will still propogate upwards.

It will help if you're only planning on updating the calling typedefs, but I don't see how that would work.

[Grampa_of_Oliva_n_Eden]

QUOTE(yen @ Jun 14 2007, 01:09 PM)

I think the point is basically as shown in the attached VI.

You divide the parts of the data into seperate typedefs and create caller typedefs for each of your displays. Each of the caller typedefs can display a different combination of the sub-typedefs. I don't think this really solves your problem, because modifying a sub-typedef will still propogate upwards.

It will help if you're only planning on updating the calling typedefs, but I don't see how that would work.

Let me add one more thought to this discussion.

A light clicked on when I read a post from Michael were the user was working with a situation were a ring was appropriate for the UI but the code really needed an enum.

He said something to the effect "Your UI should not dictate our data types."

So applying that thought to this thread, I would disconnect the GUI from the type def. THat way you can make changes to your data as you need and the GUI layout stays the same.

I have used this approach myself and it works fine.

Ben

[jaegen]

My $0.02CDN:

In cases where the type def needs to be cosmetic, we simply make it strict, and make all the cosmetic changes to the type def itself (this is a bit of a hassle when you need things to line up with other type defs etc., but it seems to be the best option).

We have a few cases where we need the type def to be non-strict (we need to do some cosmetic changes programmatically). In these cases, when we need to make changes to the type def we follow these steps:

1. Open the GUI VI

2. Open the type def

3. Make the type def strict

4. Make the changes

5. Save and close the type def

6. Open the type def again

7. Make the type def non-strict

8. Save and close the type def

9. Save the GUI VI

This way the cosmetic changes and the data changes get propogated.

Note that this only works for a single cosmetic instance. If you need more than one (different looking) instance of the same data, I think the best way is either to disconnect from the type def, or use two different strict type defs which contain the same data.

Jaegen