curious numeric constant behavior

[X.]

Numeric constants taken from the palette have this peculiar property that their type can be changed depending on what you type in.

For instance, grab an "orange" constant and type "1" in it, and it will turn blue. Grab a "blue" constant and type "1.0" and it will turn orange. Neat.

Now, what happens if you have the following situation:

Well, for a fraction of a second, you'll get this:

and then, right after that:

Darn! The conversion failed...

If you drop a constant from the palette or select the blue "1" above and Right-Click>>Representation>>DBL, of course things work fine and you get the intended result:

Feature?

[nathand]

If you right-click on a numeric constant dropped from the palette, you'll see that there is an option "Adapt to Entered Data" that is checked.  When you create a constant on the block diagram, LabVIEW knows the type of data for which you're creating the constant, so you get a constant of the same type and the Adapt to Entered Data option isn't checked.  To me this makes sense.

[X.]

You are describing the first step (create a constant, it is blue).

I am complaining about not being able to override this choice AFTERWARDS.

[nathand]

You're asking for the "Adapt to Entered Data" option to be set on constants that are created, not just ones that are dropped.  When you create a constant on the block diagram, LabVIEW already knows the type of the wire, so to me it makes sense that it picks the appropriate type.  Let's say I'm bundling a U8 value into a cluster, so I right-click on the Bundle by Name and create a constant.  I get a constant with the representation set to U8.  If I change that value to 5, I don't want the representation to change to an I32- which is what would happen if the "Adapt to Entered Data" option was set.  To me, the current behavior is the expected and reasonable behavior.

[X.]

Then the option should read "Adapt to Entered Data no matter how frantically the user wants to change that" 🙂

I don't say it does not make sense, I am just saying I found this unatural at first and annoying eventually. But now I am saying it!

I don't see that there is an option which would disable that behavior?

[nathand]

---

@X. wrote:

Then the option should read "Adapt to Entered Data no matter how frantically the user wants to change that" 🙂

---

Maybe there's a language issue... why would you rephrase this?  "Adapt to Entered Data" is clear to me.  It means that when you type in a floating point number, you get a double-precision value.  When you type in an integer you get an I32.  When that option is NOT set, the data type is fixed by whatever representation is chosen.  I don't see any preference that would let you change the current behavior, but I would not want Adapt to Entered Data set on constants that are created on the block diagram, which is what you seem to be asking for.  If you want to be able to drop constants that don't adapt, you could do that with a merge VI in the palette.

[X.]

Yes, sorry, I just got confused. Let's leave the "Adapt to Entered Data" option as is. I shouldn't be typing and wiring at the same time.

I was just annoyed by the fact that a constant created on the block diagram had this option unchecked, indeed. I don't see what the caveat with this would be (that is, create it with the option left checked)? If the user wants to create coercion dots all over the place, shouldn't it be their right? Notice that in the case I was illustrating my question with, I am actually doing something that makes very much sense. I think.

[nathand]

---

X. wrote:

I was just annoyed by the fact that a constant created on the block diagram had this option unchecked, indeed. I don't see what the caveat with this would be (that is, create it with the option left checked)? If the user wants to create coercion dots all over the place, shouldn't it be their right? Notice that in the case I was illustrating my question with, I am actually doing something that makes very much sense. I think.

---

I disagree that this makes sense.  If you want the output of that tunnel to be a float, why did you wire an int to it in some other case?  I find it less confusing than the example I provided, where I know I want a U8 (because that's the data type in the cluster) but Adapt to Type changes it to the default integer type (I32) when I enter an integer value.  I like that the default behavior prevents unexpected coercion, and I have to manually force a coercion if that's the behavior I want.

[X.]

OK, the simplified example I gave might be questioned (as you do). The original diagram was more complex and one case (the one I treated first) had an integer wire connected to a "Multiply" function, one connector of which was DBL. Seeing that, wanting a constant of 1 in the other case, I was planning to cast the wire to DBL by creating a DBL constant and that's when I got my mini-commotion...

I guess there is no point arguing further and for me to try suggesting to leave the option of "Adapt to entered data" for constants created from the block diagram 🙂

[X.]

This stuff is everywhere:

That constant also has its "Adapt to Entered Data" unchecked. So basically if I wanted to also use that constant 4 to do a bunch of double precision calculations, I would have as many coercion dots instead of one?

That's arm twisting IMO. I just don't like the idea of having a functionality (adapt to entered data) which is sometimes available and sometimes not, due to some internal decision of NI.

But I guess, reading this, this and that, that I am pretty alone on this one... 😞