Feature Request- block diagram terminal shows when numeric inputs are set to "Coerce"

[Robert_Hohlfelder]

Digital controls on the front panel can be set to coerce user-entered values to specified minimum and maximum values using a property panel. This is very convenient. However, there's no obvious visual indication that this property has been modified from "Use Default Limits". A colleague inherited a SubVI where some front panel control values were being coerced through code on the block diagram. What he didn't know was that the control properties were also set to coerce, and to different values. It took him a while to figure out what was going on. 

What if block diagram terminals had some visual indication that their control no longer has the "Use Default Limits" property set? For example, see attached sketch. 

[crossrulz]

I'm actually against a visual indication on the terminal.  But it would be really nice if this information was added to the context help.

[fabric]

Big fat kudos.

I would happily take this idea as it stands, but I think a much more powerful variation would be to indicate *any* non standard configuration. E.g. if a (non-strict) boolean typedef is set to "Switch when pressed" then I'd love an indication that a particular instance of that typedef has been changed to "Latch when pressed".

Not to detract from the idea as it is presented, but I'd rather see a glyph that simply means "Hey - I'm different!" so that I can then follow the context help for full details about what those differences are.

Aisde: I'm sure I've seen this general idea raised before but the search failed me...

[SteenSchmidt]

I have my doubts about the value of highlighting that coercion is configured on a control. I mean, the user will notice it anyway, when entering values outside the coercion limits and the values get coerced. And the coercion have no effect on programmatic input, so who should it benefit?

/Steen

[fabric]

Steen, I believe the OP is actually talking about an edit-time indication. He mentions an indication on the BD, but for the record I'd prefer a FP indication that is only visible at edit-time. CH would be fine too as crossrulz suggests.

Either way, an indication would be extremely helpful in many cases. A few examples:

• Replacing an old control with a typedef without realising the original control had a special configuration
• Copying an old control (with coersion) to a new location and then wondering why the new control is behaving strangely

These days I find myself programmatically setting any non-standard behaviours but this seems like a disproportionate amount of work for occasional benefit.

[AristosQueue (NI)]

I support the general idea but not the specific suggestion. But I also don't have a better suggestion to offer.

I've discussed this in person before with various users, and it has been a problem for me when inheriting code. And yet I end up completely split on what, if anything, LabVIEW should do about it.

On one hand, I get that it is important to know that something is non-standard configured, and it would be nice if that information were somehow pushed to you. On the other hand, there are so many options on a control/indicator that aren't visual that it would be impossible to visually annotate each one without a large block of text hanging on the panel. If you just have some marker that says "this has a non-default configuration" then that would be just as useless, I think, since so many control do something that isn't quite standard, at least on the end-user visible panels where this is usually relevant.

I haven't really liked any idea I've heard suggested, but I agree it would be nice if something were improved in this domain.

[Robert_Hohlfelder]

I think fabric's two posts are stronger than my original post. It can be easy to lose track of when a FP control has been configured in a that affects its behavior; visual hints would be helpful. Performing coercion programatically on the block diagram provides a way for the programmer to be explicit about intended behavior. On the other hand, coercion of the front panel control is such an easy way to implement the desired behavior for user-facing controls. 

[fabric]

AQ - I can understand your concerns regarding visual noise...

So what if this only applied to non-strict typedefs? What if we simply modified the black triangle in the upper left corner (e.g. to be grey instead of black) if the config had been somehow modified from the original typedef? The burden would still be on the CH to explain the details of what has changed.

Overall this would be a minimum of extra visual noise, with the bonus that less sophisticated users who don't use typedefs would be spared from the lexical jargon completely.

(New idea required obviously...) 

[crossrulz]

But what about those non-strict type defs that have been modified? They still have the black triangle.

[fabric]

---

@crossrulz wrote:

But what about those non-strict type defs that have been modified? They still have the black triangle.

---

Huh? This is how it would be:

• All typedefs get a little triangle
• For strict ones it is always black
• For non-strict ones it is black for any instance that matches the .ctl file, i.e. unmodified from default configuration
• For non-strict ones that have been modified the triangle is grey

I'd also add that when I say "modified" I mean modified in internal configuration or behaviour (like numeric coersion settings), not a pure cosmetic change (like making the FP control bigger).

I fear there may be some grey area in defining "config vs. cosmetic" but at this stage I'm just looking to salvage something out of the idea...

[tst]

One point which hasn't really been brought up is that this is an edit time indication, but these options can also be set at run time, as fabric alluded to. Not necessarily a reason not to do this, but a point for consideration.

As for alternative UIs, here's a one-thousandth-baked idea:

Have an additional panel (docked/floating/whatever) which will be an assistant for the VI in focus. This panel can show all kinds of relevant details based on the selections you made, filters you set in it, etc. It would then show the list of relevant objects in the VI both as a list in the panel and by highlighting them in the VI. It would be nice if such a panel also had extensions for plugins.

For example, if the filtering mechanism was checkboxes (which is probably a bad idea), you could have a "show controls with non-default data entry" and if that was checked, those controls would be highlighted.

A couple of obvious issues with such a scheme:

1. It probably doesn't directly address the intent of the idea, which I assume is to see that such controls exist without having to go looking for them.
2. Creating such an assistant would probably be difficult. Not on a technical level, as we can do that today and we don't even need NI, but the UI for it would be tricky if it needs to do a lot of different things.