Type def'd clusters - why do things move?!

[psmorris]

Why why why do things move/change size etc in type def'd clusters if I make a change to the type def. I understand that a "strict typedef" maintains both content and layout wherever it is used. A typedef is only supposed to maintain its data type throughout.

So, we have a set of type defined clusters that are used in various areas of our applications. In some applications, not all of the controls within the clusters are needed, so where they are displayed on the screen the unwanted bits are hidden, and the other items are arranged nicely and sized to fit in with whichever UI they are a part of.

I understand that if I add a new control to my type defined cluster, it will be displayed in all of the clusters wherever they are used, but why does that then completely overwrite any and all control positioning where I've painstakingly set out controls in the UI and end up completely messing up my UI!

See my before and after pictures for an example!

This is using Labview 8.6.1 - is this still going to happen in LV2011?

Paul 

[TCPlomp]

A typedef isn't meant as a GUI element, just a data-type definition. If you want aesthetics you should consider using a Strict Typedef.

Ton

[psmorris]

Here's the issue. We have a "scan cluster" which is a typedef'd cluster which we use to setup scans that our system can do. There're at least 7 different scan types and we wanted (for simplicitiy) to have one single cluster that can be used to define the scan. Not all scans require the same information, so there are sub controls within the typedef'd cluster which are or aren't relevant for each scan type. Again for simplicity we show the user the "scan cluster" with only the relevant controls for the type of scan they're doing visible. I didn't want to show them a cluster which only contained the relevant bits and then have to "build" that into type def'd cluster type in the code as that seems like duplication to me... 

So I can't use a strict typedef since you can't hide elements of a strict type def and even if you could, you can't then re-position the other controls to hide the "gaps". Instead we use "normal" typedef so that the cluster maintains data type throughout our application, the irritation comes when I need to add something to that type def (to add a new scan type, for example) the positioning and sizeing of all the elements in the cluster gets scrambled (even if all I'm doing is adding an item to an enum within the typdef!!) and I have to go back through the entire application looking for occurences of the scan definition cluster and remake the UI. 

I fully expect any new controls to be added to the cluster throughout, and I fully expect to have to go through and hide it if its not needed in each case, but why why why does the positioning and sizeing of all the other controls get completely scrambled. I would perhaps not mind so much if the control reverted to the layout of the type def, but it doesnt, everything just goes all over the place.

Its a little frustrating to say the least! 

[Ben]

Re: Type def'd clusters - why do things move?!

In the old days on old slow machines you could actually witness what happens when you update a type def'd cluster.

LV removes (yes removes complete like delete type remove) the old cluster then inserts the new version where the old one was.

Ton was on the mark about using Stricts but to fill in the gap let me attempt to paraphrase a post by Michael Avaliotis (a fellow LabVIEW Champion and fonder of LAVA) when he posted to LAVA on a similar topic.

[Paraphrasing]

"

The GUI should not dictate the data structures or vise versa. Your data structures should be designed based on the work being done and the relation bewteen the elements in the data sructures.

"

So I would suggest creating unique type def's for each presentation to the user. If you do this once the changes to the type should stop attacking your GUI.

Yes you will have to enusre changes to one structure are caried thru to the others, but good unit testing will reveal these issues easrly on.

So bottom line is

Don't let you GUI dictate your data structures.

Ben

[psmorris]

Thanks for your reply. Surely its contradictory though.

For me, it is logical to have one "scan settings" cluster used through out my application, and where necessary hide settings which aren't relevant to a particular scan type as appropriate. Then, when coding I only have to deal with one data structure if I'm writing scan code. 

It is the UI (and LV) which is now forcing me to have lots of different (strict) data structures (with many common features) for broadly similar tasks, hence it is the UI which is now dictating my data structures...

Paul

[Ben]

---

@psmorris wrote:

Thanks for your reply. Surely its contradictory though.

For me, it is logical to have one "scan settings" cluster used through out my application, and where necessary hide settings which aren't relevant to a particular scan type as appropriate. Then, when coding I only have to deal with one data structure if I'm writing scan code. 

It is the UI (and LV) which is now forcing me to have lots of different (strict) data structures (with many common features) for broadly similar tasks, hence it is the UI which is now dictating my data structures...

Paul

---

I think you and I will not come to an agreement since what it does is not what you want. Changes to accomodate your desires will require you start a thread in the LV Ideas forum and get some agreement from others.

All I can do to help you here and now is try to explain the critter and offer alternatives.

Take care,

Ben

[JÞB]

I imagine that you have some frustration in this but let's try to look at it this way.

Scan Cluster is a superset (union) of elements in

Scan Cluster (Type A)

Scan Cluster (Type B)

Scan Cluster (Type C)

Scan Cluster (Type X)

Scan Cluster is the datatype that is operated on and is not presented to the user it is merely  internal and a good way to keep scan parameters in 1 location

HOWEVER, for display purposes we  do not wish to show the user irrelevant elements so we need to down-cast from the type Scan Cluster to the Strict type def Scan Cluster (of Type).  A simple class could be constructed to programatically select which type of scan we want to display and display the correctly formatted cluster.  Or, even more simply based on the type of scan format the displayed strings of the relevant cluster elenemts for user consumption (since the data type is lost on the user anyway, they see text)