Option to have default data type (without wiring a constant) at the input of Select function.

[moderator1983]

I would like to have an option, where programmer can select 'Default Data-type' at 't' or 'f' input of a Select function so that, he need not connect a constant (with default value) 

[AristosQueue (NI)]

Why are you requesting this? What is your goal?

In my view, there is no gain to the developer (the number of mouse clicks to set this option is the same as creating the constant) and there is no gain to later reviewers of the code (another magic symbol to remember what it means). You are clearly aiming to eliminate some pain point, but I'm unclear what that pain point is from the solution proposed.

[moderator1983]

More emphasis is to get cleaner diagram....!!
World is overseeing next to nanotechnology, so am I...!! 

[AristosQueue (NI)]

Speaking as a member of LV R&D: There is nothing technical in the way of this request.

Speaking as a LabVIEW user: To me, this is not a cleaner diagram. Anything that adds a new mystic symbol (your "D" glyph or anything else we come up with) replacing an existing and easily understood symbol (i.e. the constant) is not a cleaner diagram. We already have the ability to iconify constants if you want to minimize their size. No kudos from me on this.

[Ken_Naylor]

I/m with AristosQueue on this one

Right Click the 'Default Constant' and selectc display as icon and hey presto!  Cleaner diagram

[CMal]

One possible reason this idea might be useful is that it would ensure that the "defaulted" terminal automatically adapts to be the same type as the other terminal.  I'm pretty sure there have been other ideas to address this, but one way to do it is with the diagram disable structure:

[moderator1983]

@AristosQueue (NI):

Speaking as a Human: I respect every individual's thoughts and I've same respect for yours.

Speaking as a LabVIEW user: I don't agree with what you mentioned

---

AristosQueue wrote:

To me, this is not a cleaner diagram. Anything that adds a new mystic symbol (your "D" glyph or anything else we come up with) replacing an existing and easily understood symbol (i.e. the constant) is not a cleaner diagram. 

---

You'll see these so called mystic symbols with each newer version of LabVIEW. For example the 'tunnel mode' of a For loop. I do understand, with this particular change (intoducing tunnel modes), it simplifies block diagram and saves development time.. but its a matter of accepting such changes.

---

AristosQueue wrote:

We already have the ability to iconify constants if you want to minimize their size.

---

The idea talks about removing the constant completely.

P.S.: I really appreciate you for going through this idea and sharing your comments.

[Darin.K]

If you want to clean up the diagram, no need for constants or glyphs, just make that input optional.  Let the compiler plop a virtual constant there, the fact you can 'Create Constant' tells you it already knows the type and therefore the default value.

This way gets you the auto-adaptation if the type changes like CMal's version showed.

It is a byVal world, it makes little sense that unwired is not ok, but right-click Create Constant changes nothing yet now is a-ok.

Make warnings, style guides and VI analyzer tests if you like, but I say as far as the compiler is concerned it should run unless there is a very compelling reason not to.

[GregSands]

I thought initially I completely agreed with Darin, but then wondered where that could lead.  Should the same apply to Plus (unwired = +0)?  Then Multiply (is unwired x0 or x1) - or Divide (/0 or /1)?  Isn't it more helpful to know that you've forgotten to wire the second input?

What I do agree with him with is that if it implemented, it should be automatic with no glyph or menu.

[AristosQueue (NI)]

The tunnel mode is a good comparison. In my opinion, the difference between the tunnel mode and your idea is that yours is a direct substitution while the other actually simplifies the work needed to write the diagram and makes it clearer the intent for a reader. The constant-to-D-glyph is a box-for-box substitution. The tunnel mode gets rid of lots of cruft and requires far fewer mouse clicks to write.

> The idea talks about removing the constant completely.

Ah, you miss my point -- your idea does not, in my view, remove the constant completely. It's still there. It just has a new form -- the D glyph. You still have to turn it on, using the same number of clicks as creating the constant. Sure, it's pinned to the node, but it is still there. If the movement is the concern, I'd happily consider a "joining mode" where the constant and its wire move whenever the node moves, but I'd leave the visual as the constant.

For the record, I'm fairly consistent on this issue -- I was and am generally against iconifying diagram constants, which is also a box-for-box substitution. Between the confusion of people asking "what is that thing? Is that an FP Terminal?" and the bugs introduced when the value is not the default value (and, yes, those have been escalated to my desk a couple times), I really don't think it does much other than let people cram a constant into a very small space. If R&D had just fixed the behavior so that typedefs didn't resize to default size when they updated, I would've been happier.

[AristosQueue (NI)]

GregS:

> What I do agree with him with is that if it implemented,

> it should be automatic with no glyph or menu.

So... just make one terminal be Recommended instead of Required?

Darin:

> It is a byVal world, it makes little sense that unwired is not ok,

Except that it helps a lot with preventing programming mistakes. That's exactly the sort of terminal that I will frequently forget to wire. I wager 90% of terminals on my subVIs are Required... and that 10% is mostly error clusters.