I liked the new DBL on the palette that we got last year or so - saves a step. But, it should NOT adapt to entered data by default! Why would I specifically place a DBL only to have it change?
If this really bugs you, like it does me, then you can find the path for the DBL constant in vi.lib (it is a VI which is set to place contents) change it and find happiness. Simply edit the palette, find this item and show the path to locate it.
I think I would like a constant that would adapt once. I can use the 2. trick once and then no longer worry about it switching back and forth. Who really changes the representation from orange to blue repeatedly. The other choice is to allow blue to orange adaptation when a decimal point is entered but not the reverse.
If I made this change, then the two numeric constants would have a different option set on them when dropped. Is that ok? I'm inclined to say it might be confusing later to have numeric constants dropped in various places of the diagram, that may be the same data type, but have a different "Adapt to Entered Data" settings. What do y'all think?
Maybe simply modify the Context Help of the numeric constants to clarify this? The features are well explained in the Detailed Help, but who would bother to read it for constants? 🙂
While those who come from text language backgrounds may find typing a decimal point after an integer value to force the representation to remain DBL, it does not seem to be what one would expect from LV. Now that we have both integer and DBL constants, I do not think adapt makes sense for either.
Typing "1" into a blue constant does not change it from I32 to U8 or I8 or any of the other possible representations which would support that value.
To be honest, I hadn't noticed that we added a double constant to the palettes until I read this post.
Let's step back for a moment and let me ask what motivated this addition. Yeah, I could look in Perforce, find out who made the change, and ask them, but I'm sure it came from customer feedback. And this forum post seems to have gathered some interested parties, so I'll start here.
By adding this double constant configured to adapt, we haven't added any new functionality, as you've figured out. All we seem to be doing (and please correct me if I'm wrong) is trying to address a perception problem... Customers who know enough that "blue" means integer, and that's not what they want. Where is that floating-point constant?
As part of this, we seem to be targeting customers who know "blue == integer", but don't know that you can type floating point numbers into the constant, and don't know that you can right-click on any numeric and change its representation. I bet these are customers who only need int32's and double's in their applications--or rather, don't know when they would need anything else.
Are there better ways to address this perception problem? Here are some thoughts...
* Don't make the numeric constant on the palettes blue or orange. Maybe black on the palettes? Maybe even black on the diagram until you type into it. Maybe even black on the diagram unless you specifically change it. (Though the wire coming out shows the proper color.)
* Don't put "123" into the icon on the palettes.
* [Bad idea] Make a palette from which you can drop every flavor of numeric (int, float, complex) of every size.
I don't particularly like any of my ideas, but I wanted to start some discussion that might lead us down a path to a stronger solution than what's proposed so far.
Brian, I think you are over thinking this Idea. The point is, IF we are going to have a DBL on the palette, THEN don't have it adapt. Even if I type a 0 in there, it becomes blue. Yet... it starts of at 0 and is a DBL. Hmmmm.
To me, it's all about minimizing clicks and frustration.
The DBL is a VI anyway. Changing it to Not Adapt is cake, and is the intuitive alternative according to me.
As one of the internal people who influences what LabVIEW is, I have to overthink the situation. I don't like the inconsistency that's being proposed. I think being inconsistent is harmful to the learning process for new LabVIEW users.
Of course, I also think the existing behavior has a different kind of inconsistency that I'm not particularly happy with. In this case, I think someone under-thought the situation.
Basically, I think the tweak doesn't solve the problem we were trying to solve when we added a double to the palette. I'd rather not make a tweak that's not clearly better than where are now. If we're going to tweak something, I'd remove the double from the palette.
