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?
I guess I consider myself a customer in some sense of the word... 🙂
I added the constant in 2010, simply because I wanted speedy access to the DBL data type (via Quick Drop)...it allows me to skip the step of right-clicking the default numeric constant and changing its type. So the motivation for the DBL constant on the palettes was more for speeding up advanced users.
I'd say 90% of the time, I'm using the constant purely for its data type, so its default value of 0 is fine for me. On the rare occasions where I need to change its value, and I need a whole number as the value, I've gotten into the habit of typing a '.' after my number to maintain the data type of the DBL constant.
With a name like 'DBL Numeric Constant' auto-adapt does seem a bit counterintuitive, moreso than two different behaviors. I suppose it is also nice to drag this guy directly to an array container to create a DBL array constant.
Only a very select few of us around here seem to be able to modify the palettes to fit their personal QDropping preferences, the rest of us remain stuck with the conventional means to customize the palettes. I am a huge proponent, a few dozen strategic items can reduce thousands of clicks, even for a casual user such as myself.
However, much like some people who don't want to fly first class because they may have to return to coach someday, many people are afraid to customize the palettes because they may get to some machine which does not have the same setup. Their loss, but it could, should, and must be made easier. There are literally dozens of ideas which are devolving into this same "we must endlessly debate the exact configuration of this palette item", when the real path to nirvana is a method to make palette customizations easy to make and easy to transport from machine to machine. I can do this to keep all of my personal machines in sync, but it involves synchronizing a lot of different files in different locations using a thumbdrive or my DropBox.
I say spend less time debating these issues and more time developing a method which allows users to customize the IDE (palettes, options, etc.) and easily use these customizations on any machine in a non-destructive way. I should be able to come to your computer, boot LV and choose my configuration. After I am finished my settings should be forgotten.
I like Brian's train of thought on making the Numeric Constant more generic. But I also like having common configurations available on the palette for convenience (not discoverability), as per Darren. The convenience motivation is not Quick Drop-specific; it also helps out the old-fashioned click and drag crowd.
To me, the names already signify the difference in behavior--one is generic and one is specific, so it feels consistent that the specific one would not adapt and the generic one would.
I would propose implementing the original idea for DBL Numeric Constant, changing its palette icon to "1.23", and pursuing some form of visual generalization to the Numeric Constant.
I find the current behavior very frustrating. I want a float constant, so I select the float object from the palette. LabView formats this as "0", type DBL. I enter "1" because I want it to be 1, type DBL. (That's why I picked a DBL from the palette!) LabView changes it "1", type I32. I get annoyed. I type "1.0". Labview changes it to a DBL and then, because of the default formatting rules for floats, Labview removes the ".0" and displays the value as "1". This helps ensure I'll repeat this cycle of frustration next time I edit the constant.
It is the unwarranted reformatting of what I typed that makes this behavior is so completely maddening. Did I not just type "1.0" into my source code? Then why did LabView delete what I typed and replace it with "1"? Such behavior would never be acceptable in a text-based programming language; why is it acceptable in LabView?
I've been programming in LabView full time for 12 years and I've never once found a time when I found the Adapt to Entered Data feature anything other than an annoyance. I always look for an existing block diagram constant (where I've turned "Adapt to Entered Data" off) that I can control-drag copy instead of using the palettes.
I understand that you cannot change the default behavior for compatibility reasons. However, I would very much appreciate it if NI would add a settable option that (defaulting to True) for "block diagram constants Adapt to Entered Data". It would certainly increase my productivity.
I would further request that the default formatting rules for floats be changed to show the decimal point, but that it a topic for a different post...
Thanks for listening!
Rob Calhoun
For me is frustrating and counterintuitive too. If I have two numeric constant options, and I consiously selected the double, it certainly is because I am going to be working with doubles. If it turns out the number I write in is the same as an integer, there is no valid reason why LabVIEW has to change it to an integer.
