LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Independence from Strict Type Definition without Representations

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

UI Representation


VI with Functional Representation

 

VI with Functinal Representation

Message Edited by LabBEAN on 07-03-2009 11:36 AM
Message Edited by Support on 07-09-2009 10:26 AM
Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
27 Comments
Trusted Enthusiast

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.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Active Participant

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.

Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Trusted Enthusiast

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

Active Participant

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
Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Active Participant

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.

 

 

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Active Participant

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.

Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Active Participant

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.

 

 

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Active Participant

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 Smiley Happy

Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Active Participant

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.
Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Proven Zealot

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.