Independence from Strict Type Definition without Representations

[LabBEAN]

Have you ever had a cluster or control where you needed a user-friendly appearance on your main VI or dialog VIs but desired a more functional appearance on your subVIs?  Traditionally, you might create a Type Definition and customize each instance.  However, if you make a cosmetic change, you have to do it to all instances individually.  Or, worse, if you make a data type change (e.g. add a new Boolean to your cluster), then all instances reset to match the new CTL file appearance *Ouch*.  Or, to avoid this, maybe you created a Strict Type Definition, and lived with dysfunction on your subVI panels.

This idea would allow you to:

- Give a Windows dialog look to strict type def instances on UI panels while providing a more functional look (e.g. showing all controls organized logically) for subVIs
- Show / hide certain controls for certain use-cases
- Appease those end users (who usually also want everything simultaneously visible on the panel) that demand a certain SIZE for controls and indicators that is not useful for subVI I/O.

Why not store multiple representations in your Strict Type Definition CTL file?  Then, open any parent VI panel, right click the border of the strictly type defined cluster, and select from the named representations you've previously created!

See below:  Imagine taking your laptop to the customer site and not having to scroll around looking for your error clusters!


UI Representation




VI with Functional Representation

Message Edited by LabBEAN on 07-03-2009 11:36 AM

Message Edited by Support on 07-09-2009 10:26 AM

[JackDunaway]

Although initially this idea seems like it would be helpful, I think programmers will run into limitations with displaying a typedef'd cluster on a UI. Directly linking the clustered data to clustered FP controls/indicators I think should be limited to VI's that only developers see.

Enter the XControl.

[LabBEAN]

Not sure what "limitations" you're referring to:

If you mean static data ranges on strictly typed controls, I agree.  But, the example I posted doesn't require instance specific input ranges on the nested controls.  (Most applications wouldn't.)

If you mean the beloved, yet undesireable, cosmetic look of a typical LabVIEW cluster, check out the first image I posted.  It's a cluster, but appears as individual controls.  (Enter the Classic Cluster, transparency, and System Controls and Decorations.)

An XControl wouldn't properly address the challenge described above.

[Intaris]

Of course an XControl can do this if coded properly.

I have developed a LVOOP-based XControl which could load different versions of a control or indicator.  This would even be customisable by the end-user AFTER compilation of the program.......

[LabBEAN]

To reiterate:

"XControls wouldn't properly address the challenge described above".

That is:

Who has time to create and manage XControls for every use-case when the functionality could be built into the Control Editor?

Message Edited by LabBEAN on 07-03-2009 03:08 PM

[Mads]

Good idea. Let me add though that cluster containers in general should not have any GUI presence during run-time. No visible cluster frame that might be highlighted or tab-navigated to; causing end users to be presented with an object they *never* need to be bothered with.

 (Sure - you can fix parts of this by editing the tab navigation properties...but it should not have been an issue in the first place considering how utterly useless the container is for the end users.)

Ideally cluster elements should not even have to be grouped together on the front panel...but that would be a much harder thing to implement in an orderly and intuitive manner.

[LabBEAN]

Thanks for the support Mads.

We've had several projects where we've run into this issue.  From a development perspective, our UI implementations haven't caused problems and using the same type def saves time.  From a user's perspective, as seen by the first image above, there is no perceivalbe difference between a cluster of indicators or several discrete indicators.

For a cluster of controls (instead of indicators), as you may have been thinking, Damien discusses programmatic tab order here.  See my post at the bottom of that link for a download.

[Mads]

Yes, the post from Damien is about the issue I was writing about. I think it's wrong for that code to be required, simply because if LV behaved like that in the first place no one would ever miss the current behaviour.

[LabBEAN]

Agreed.

I think I'd use the programmatic tabbing anyhow since it saves you from "Edit >> Set Tabbing Order" and going to unwanted controls and setting"Key Navigation >> Skip this control when tabbing".  Also, it's handy if there are controls within the cluster that don't make sense for the user to tab to (e.g. an array, slider, etc.).

BTW, I've asked the moderator to correct my spelling in the title.  Maybe we'll get some more votes 🙂

[LabBEAN]

Also, as Simon points out, XControls have their limitations:

• You can't have an array of XControls
• XControls don't run constantly (your code gets called to handle events)
• XControls get called even in edit mode (if it's on a front panel in memory you can't edit it)

For another example of a type def'd cluster (inside an array) on a UI, see here.

[AristosQueue (NI)]

Similar to this idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Strict-Type-Def-of-Type-Def/idc-p/1135856#M5700

If you kudos one, you probably want to kudos the other.