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]

Glad to have your support, AQ.  Not sure why the community at large hasn't come behind these ideas.  (The CLA / advanced user support for both is relatively high.)  Perhaps most aren't aware of programmatic tabbing...

Thanks for the cross post.

[AristosQueue (NI)]

> Not sure why the community at large hasn't come behind these ideas.

This is a LV architect's problem, not a LV programmer's problem. 

Differentiation of implementation from interface is something that *only* the CLAs are going to even recognize as a problem, much less see as needing a fix. Very few people would ever typedef a plain integer in order to differentiate it from any other plain integer. Even fewer would want a front panel control that showed the difference between integer A and integer B. If they did, we would hear a lot more use of (and more demand to improve) units.

[JackDunaway]

My original comment about the XControl I agree is not the most elegant solution to this problem. (XControl rhymes with "necessary evil" in my experience)

And although it's a clever workaround for crummy built-in functionality, I don't see how programmatic tabbing applies here...

And I must be really obtuse, but how is this Idea the solution to an "architect's problem"?

Yes, I can see clear benefits in implementing this Idea - that is, if your underlying datatype elements have a 1:1 relationship with the UI elements.

I will illustrate this point by showing some potential flaws in your example: "Profile Running" and "Profile Complete" are mutually exclusive, no? Wouldn't it be better to have a single enum named "Profile" with three elements "Idle, Running, and Complete" for the underlying datatype? Having two mutually exclusive pieces of data in an underlying datatype is among my favorite of code smell indicators. Also, the underlying datatype probably only needs "Forward Miles" and "Reverse Miles" since "Total Miles" is derived. Exclude "Total Miles" from the underlying cluster and just show the sum for display.

Another argument against using a 1:1 relationship: the customer now wants to multiply speed by -1 if Direction==Reverse and not show the Direction enum on the UI. The data source (the VI that generates the data) would need to be updated using your 1:1 relationship. Using underlying data different from the display data, only the data client (the UI front panel) needs to change. I would be much more inclined to service the UI FP for a cosmetic upgrade rather than tracing the data source back through the HMI framework, through TCP, back to the RT, back to FPGA...

Basically... I question a perfectly overlapped Venn Diagram where the set of data shown to the user equals the dataset used for underlying data processing/messaging/storing. The underlying datatype should be as stripped and streamlined as possible, while the display datatype can inherit all the flair and post-processing that Upper Management wants to see in a UI.

---

Aristos Queue wrote: 

Differentiation of implementation from interface is something that *only* the CLAs are going to even recognize

---

I would hesitate to draw an *exclusive* link between certification and cranial prowess.

(Well, since I have admitted I don't big benefits for this Idea and I'm also not a CLA, I could be bolstering your statement...  )

[LabBEAN]

---

 @JackDunaway wrote:

And although it's a clever workaround for crummy built-in functionality, I don't see how programmatic tabbing applies here...

---

 See comment #5 by Mads (and subsequent).

---

 @JackDunaway wrote:

And I must be really obtuse, but how is this Idea the solution to an "architect's problem"?

---

The essence of AQs comment is that most LV developers aren't interested in the appearence of their subVIs and even less in the intricacies of type definitions (therefore... they won't spot deficiencies).

---

@JackDunaway wrote:

I will illustrate this point by showing some potential flaws in your example...

---

 The data you see maps directly to tags on the PLC.

---

JackDunaway wrote:

Yes, I can see clear benefits in implementing this Idea - that is, if your underlying datatype elements have a 1:1 relationship with the UI elements.

---

  😄

 

---

@JackDunaway wrote:

I would hesitate to draw an *exclusive* link between certification and cranial prowess.

---

 This is really a discussion about exposure, not intelligence.  It is worth noting, though, that both parallel ideas have been submitted by Certified LabVIEW Architects.

Message Edited by LabBEAN on 05-27-2010 09:52 AM

[JackDunaway]

---

LabBEAN wrote: 

---

JackDunaway wrote:

Yes, I can see clear benefits in implementing this Idea - that is, if your underlying datatype elements have a 1:1 relationship with the UI elements.

---

 

---

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).

***EDIT: By all means, please start a discussion on the LabVIEW board so we're not hindered by the Exchange's interface. ***

Message Edited by JackDunaway on 05-27-2010 10:04 AM

[AristosQueue (NI)]

> I would hesitate to draw an *exclusive* link between certification and cranial prowess.

In this case, when I say "CLAs", I include those who have passed and those who have not  yet taken the exam but could pass. I probably should've just said "LAs", but I doubt that would've clarified anything. 🙂

[JackDunaway]

It's hard to convey a light-hearted jab via message board, but that was my intention - I understood what you were trying to say. Drawing a hard link between certification and capability is like being naïve enough to draw a hard link between "pregnant-looking" and "pregnant".

[LabBEAN]

...you mean "passing a pregnancy test" and "pregnant"?

EDIT:  before you read that wrong... I agree that you can be "pregnant" without "passing a pregnancy test"...

Message Edited by LabBEAN on 05-27-2010 01:45 PM

[JackDunaway]

Ay de mi, jokes are much more effective when you word them carefully enough that people understand them the first time.

Looking at someone who is "pregnant-looking" and assuming they are "pregnant" is like looking at someone who is "certified" and assuming they are "capable" or "experienced" or "intelligent" or fill-in-the-blank. Asking a "pregnant-looking" lady when her baby is due is as risky as assuming that someone who has passed a test is capable of architecture.

[LabBEAN]

AQ was saying there are more "LAs" than there are "CLAs".  To apply that to your illustration, there are more "pregnant women" than there are pregnant women who have "passed a pregnancy test".

[I suppose there could be CLAs who are not "capable of architecture", but that wasn't the essence of his comment (and is arguing from the negative).]