Type defs changes not reflected in block-diagram constants?

[Thoric]

I'm struggling with strict type-defs today.

If I create a strict type-def, say of a cluster with an enum in it, and save it. Then create a block-diagram constant from the strict type-def in a blank vi. Then make changes to the strict type-def (say, add another item to the enum), the block-diagram constant ghosts out , as it should. If I then select "Apply changes" from the strict type-def menu, the ghosted block-diagram constant becomes un-ghosted, as it should. BUT, it hasn't update!? If I look for the new item in the enum, it isn't there!? I'm sure it should be, right?

No changes that I'm making to my type-defs or strict type-defs are being reflected in my block-diagram constants (which are definitely still linked to the controls with "Auto-update from type-def" checked on). It does work for front panel controls and indicators though - just not block diagram constants.

I'm using LabVIEW 8.5.1, Win XP Pro. Any ideas anyone?

[Thoric]

OK, I have more info, and I wonder if this is a bug now. Maybe the regular forum gurus could take a look and comment?

The strict-type-def is a cluster and the enum control within it is not a type-def, and it appears that block-diagram constants created from this custom control do not update when the non-type-def enum within the cluster is altered. Front panel controls and indicators will update however. The solution (workaround?) is to customize the enum within the cluster and make it itself a type-def, hence we have an enum type-def within a cluster type-def (two files for the price of one). This nested type-def status ensures that block diagram constants also update when changes are applied.

Anyone think this might be by design? I certainly don't expect front panel objects and block diagram objects created from the same strict-type-def control to behave differently when the control is modified. I wonder if this is a bug?

[Thoric]

Ok, scratch that. I thought the workaround worked, and it did for a while, but now changes to my strict-type-definition clusters with strict-type-definition enums inside are still not reflected in my block-diagram constants - even though they all say "Auto-update from type-def". Nothing I do seems to guarantee these constants will update following modification of my type-defs. I think it's time to call Technical Support.......

Message Edited by Thoric on 09-10-2008 01:51 PM

[Ben]

Fast reply.

Strict only applies to GUI object not block diagram.

Post images to illustrate your concerns so we can be of further assistance.

Gotta run!

Ben

[Thoric]

Solved. I think.

I tried a range of type-defined controls, including an enum, a ring list, a cluster with an enum inside it, and a cluster with a ring list inside it.

Changes to the enum items were reflected in all vi controls and block diagram constants.

Changes to the ring list items were not reflected in the controls or block diagram constants.

This snapshot shows the the last item available in each ring and enum list. Clearly the rings were not updated when the custom controls were. (Yes, I applied changes and saved too).

 

Switching to strict type-defs only impacted  the front panel controls, as Ben highlighted, because this is GUI related. You can see from this second snapshot where all type-defs are now strict type-defs that all enums and rings updated to reflect all three items, but the block diagram rings are still out of date

 

I expect somebody will tell me now that this is normal behaviour??? 

Message Edited by Thoric on 09-10-2008 02:31 PM

[Ben]

See here.

The string are part of the enum data-type (ie they are "in" the wire). They are not for rings. Se above thread for more words on this subject.

Take care,

Ben

[Thoric]

Ah, I see. The thread you link to makes a lot of sense, thanks.

I just wish this behaviour could have been more intuitively determined myself somehow. Alas, I've lost an hour of the day to trail and error testing 

Thanks for the responses Ben!

Message Edited by Thoric on 09-10-2008 02:46 PM

[DFGray]

I know of very few hardcore LabVIEW programmers who have not gone through what you just went through ( those that didn't read the forums ).  If you have any ideas on how to make it intuitively obvious, please let us know.

[Ben]

---

DFGray wrote: 
...  If you have any ideas on how to make it intuitively obvious, please let us know.

---

As much as I HATE it when the palettes get re-arranged....

How about putting the Ring control on the numeric palette and putting the Enum on the string palette?

With the two being side by side the there is an implied similarity.

Just thinking out loud.

Ben

[Thoric]

I like this idea, Ben, although it may seem confusing to novice programmers as the enum doesn't provide a string type but instead an unsigned integer of some form, as does the enum.