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

[LabBEAN]

=======

JackDunaway wrote:

This is a good indicator that we're both aware at this point that I'm missing something... in all seriousness, could you reply to the 1:1 argument? I really want to understand this Idea and learn how/if I need to apply it to my own style (our last back-and-forth turned out to be an enlightening and introspective exercise for me).

=======

I'll try to find some time to start that discussion on the forums, as you mentioned...

[AristosQueue (NI)]

Right, so for future reference:

LA = LabVIEW Architect

CLA = Certified LabVIEW Architect

ACLA = Accurately Certified LabVIEW Architect

ICLA = Inaccurately Certified LabVIEW Architect

PLA = Pregnant LabVIEW Architect

PCLA  = Pregnant Certified LabVIEW Architect

CPLA = Certified Pregnant LabVIEW Architect

CPCLA = Certified Pregnant Certified LabVIEW Architect

ACPACLA = Accurately Certified Pregnant Accurately Certified LabVIEW Architect

Or, as a regular expression:

[[[I|A]C]P][[[I|A]C]]LA

[LabBEAN]

*tear* (my wife's pregnant -- does that affect my acronym?)

[JackDunaway]

@Aristos: You have fulfilled your elaborate fantasy scenario of the day - an awesome kick-off to Memorial Day Weekend. @JackDunaway: Comparisons that seem acute and legitimate in your mind need to pass through a bandpass filter or unit test before making it to the forums.

[shb]

I marked related ideas with the tag style.

And please, vote for this idea(s)!

[LabBEAN]

<<JackDunaway wrote:

This is a good indicator that we're both aware at this point that I'm missing something... in all seriousness, could you reply to the 1:1 argument? I really want to understand this Idea and learn how/if I need to apply it to my own style (our last back-and-forth turned out to be an enlightening and introspective exercise for me).>>

Okay, Jack.  Sorry for the long delay.  Continued here.

[LabBEAN]

Mentioned this in the link above:

The beauty of this idea is that the developer can define whatever kind of views he/she wants.  Controls and indicators of the same type def could have different views.  That is, Cluster.Boolean1 could be a button or an LED depending on whether you place the containing cluster as a control or indicator.  The same would be true for non-cluster data types.

Jack - Thanks for your support and congratulations, btw, on becoming a CLA!