Front Panel Object's Style is shown under its properties

[leahmedwards]

When I was newer to LabVIEW, I found it hard to understand how people could identify front panel object styles e.g. NXG style string control vs System string control. 

I believe it is the sort of skill that takes experience and experimentation, and it only gets more complex when the appearance of the string control is customised. For example, modifying the above controls so they are the same size, they are practically identical...

I have never been able to find a good complete documentation of the differences in appearance and behaviour between different styles of front panel object - seems each style of each type of control has their quirks. So when presented with front panel objects that you did not make yourself, it is hard to 'reverse engineer' them if changes are needed. This makes it harder to learn how to make good UIs.

A potential solution would be to add a property which tells you which style a control or indicator was created as, or most recently replaced by. E.g. modern, classic, system, silver, NXG. An extension would be to add a 'reset to default style' which would behave as if replacing the customised object with an object of that style from the palette. A further extension would be to allow changing of style e.g. in this example from NXG to System via a dropdown box, although not all front panel objects are available in all styles so I can see this being more difficult to implement.

This is probably the ugliest UI mockup you will see all day but I hope it gets the idea across and sparks some conversation:

This would be accessed via 'properties' on the right click menu of the front panel object.

I'm not very experienced with XControls, QControls etc. so would welcome suggestions about how these should behave. Perhaps there is some nuance to do with styles that I am missing.

This idea is related to this one which talks about setting style for the whole front panel.

Let me know your thoughts!

[OneOfTheDans]

This would really help cleanup the palette & quick-drop too! Classic/System/"Modern"/Silver/NXG would all consolidate if you could just create using your default template style, and change using right-click/properties/scripting.

[leahmedwards]

@OneOfTheDans "Modern", made me chuckle! 

Thanks for your suggestions. I can see the argument for simplifying front panel Quick Drop, especially seeing as you can set default styles in the LabVIEW Options menu, as you say. Though the case where you Quick Drop a control type that exists in multiple styles but not your default could get confusing - how would it choose which to display?

Because the palettes are currently sorted by style and each style has different offerings, I find it harder to visualise a palette that didn't separate out the styles. The visual differences could end up looking jumbly if you didn't limit it to a single style per palette, which again is a consideration for the case where there is a control type that exists in multiple styles but not your default. 

[AristosQueue (NI)]

> "Modern"

We did create post-modern controls, but the deconstruction they did on user data was painfully self-reflective and the six-point perspective made the UI really hard to use. So we'll stick with modern controls, thanks.

🙂

[wiebe@CARYA]

I could be wrong, but I doubt a control has any knowledge of it's style.

A control's 'style' is simply the place where it's been placed on the palette.

The standard controls aren't type defs, so even back tracing to it's file location to find the style could be hard.

I think adding this feature would require a new property containing the style. Of course a tag could be used...

This property would only be available in new controls, probably even only in newly placed controls (e.g. opening an old VI will have contained old controls that don't have the property).

Implementing this might be much harder then you'd think.

EDIT: BWT such a property might be needed. I know people have been looking for it...

[OneOfTheDans]

@leahmedwards

What I meant is if the FP objects' display style is easily switchable like you suggested, then the palette only needs to show each unique datatype once (in your chosen default style). For example, one palette item "Boolean Indicator" would replace everything below. All these would still be Style choices in properties (or right-click).

• Classic
  • Classic Square LED
  • Classic Round LED
  • Square Light
  • Round Light
• Modern
  • Round LED
  • Square LED
• Silver
  • LED (Silver)
• NXG
  • LED (NXG Style)

@wiebe@CARYA

They must have some knowledge of their style - many of the style variations have different behavior. For example System controls usually have restricted sizes and colors while other styles have more flexibility.

[wiebe@CARYA]

>They must have some knowledge of their style - many of the style variations have different behavior. 

Because the code behind it is different. That doesn't mean they know the group they're in.

[AristosQueue (NI)]

> > They must have some knowledge of their style - many of the style variations have

> > different behavior. For example System controls usually have restricted sizes and

> > colors while other styles have more flexibility.

>

> Because the code behind it is different. That doesn't mean they know the group they're in.

Summary: We could add the concept of style to new controls dropped, but today (as of LV2021), the controls have essentially no idea of their style. We would have to make a guess at styles for existing controls and for any new styles of controls that customers develop in order to make this Idea work.

Details: The code behind varies by part, not by entire control. Each control has a parts list. Size constraints are done just by adding different individual parts. Any given control is an amalgam of parts that may be reused across many styles. The closest we come to having a record of style is the large FP terminal icon, but even those icons just make educated guesses at what image to show. For example, drop these controls:

you get these FP terminals:

Two of them are good matches, but the other two are way wrong. I don't know all the things that the controls try to make a guess at those images, but there is no "style" info to provide guidance. It tries to create a fingerprint of attributes to come up with what to show. As you can see, the NXG controls were built out of parts that were so unusual that the fingerprint is not good enough to guess the icon. This all works because any user could open up the control editor and edit individual parts (and some customers have) to create their own palette of controls with their own "style" concept.

The idea is a worthy idea, but would require some rethinking of "what is a control" to implement. I will add my personal kudos to the idea, but I don't know how far it'll fly with LV R&D overall.

[wiebe@CARYA]

Also see the Ship of Theseus (Wikipedia).

I wander if such a style property would need to be customizable by the users or not.

A (hidden) tag could be a quick way out. Probably easier to implement than a property?

[cy...]

@wiebe: properties could be better, especially when used with scripting to update FP to newer looks when migrating to newer versions/systems. properties unavailable for the replaced controls can break wires, letting the user know where to fix, while others will be inherited... not sure how that would affect vision, cluster or custom controls in scripting though

[zou]

This is a good idea.

A control may have many parts, but the Frame makes it unique.

For a numeric control, if one import a System style frame, then the control's color can not be changed anymore, all parts;  if import a NXG style frame, when toggle from control to indicator, the textbox changes size.