LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
Showing results for 
Search instead for 
Did you mean: 

String Constant becomes Empty String Constant when empty



JKI Blog
Proven Zealot

Why in the world has no one ever suggested THAT before? In retrospect, that's an obvious, easy, and significant improvement to diagram readability. Gets my kudos!


* Idea if implemented should include the end-of-line and other lone whitespace constants.


(For me, this idea should win an "Altenbach 'Why aren't Boolean constants square?' Obvious-In-Retrospect Award"!)

Active Participant

Well, I have been called a master of the obvious Smiley Very Happy


One limitation of the feature design I'm proposing (that a UX designer will need to solve), is that it's not obvious to a first time user that these graphical/iconic representations of constant values are actually editable (does it change when you hover? when you click? when you double-click? And, what does it change into?).  However, if we extend the idea, as you're suggesting (hey, I see you're a master of the obvious, too!), to all the various useful constants (end of line, whitespace, etc.), then the user will probably learn (reasonably fast) that these iconic nodes are editable.


Side Note: It's worth mentioning that the only reason I thought of this was by watching how @dnatt's wonderful brain works.

JKI Blog
Proven Zealot

The mouse cursor change is a good idea for discoverability. Also, if they ever type a space and it turns into the space constant, I think most people would suspect that there's a bidirectional relationship.

Active Participant

Conversely, double-clicking on a constant probative would convert it into an editable constant?

Copyright © 2004-2018 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Proven Zealot

crelf: yes. See Kring's picture. But I am not sure how far to run with this idea. I like the idea of double clicking on "Pi" and gettting an expanded 3.141... etc. But I'm uncomfortable with typing in a value and having to match exactly the value of Pi to the nth decimal point used by the constant to have it convert the other way. The idea seems really solid for string constants and not so much for double constants.


There's another vector on this idea... some of the constants in the palettes are just linlined subVIs rather than built-in constants, but to most users, those two implementations are indistinguishable. But if a user writes a VI that has a single output and whose block diagram is a constant wired to that indicator, and it is marked as "inline", then maybe this "double click convert to editable constant" should apply? I think that's too much feature creep, but I'm poking around the edges of the idea to make sure we haven't missed something else obvious.


(Just to remind folks... me getting excited about an idea is no guarantee of it being picked up by R&D, but for ideas like this, I like fleshing them out in the forums since it can make it easier for R&D as a whole to decide to do it.)


I can think of a couple of caveats that need to be considered.


First, when an iconic node is converted to a non-displayable char, such as a carriage return char, a Display Style of Normal for the resulting string constant would be very confusing; but either of Backslash Codes or Hexadecimal would make it quite clear, especially if "Display Style Visible" is also enabled.


Secondly, it will be necessary to pay attention to the platform in the cases of platform-dependent chars, such as the end-of-line constant (\n).


But if these considerations were solved, this could also be educational, AND a way to verify code.  When the dev double-clicks on a Carriage Return Constant node, it should turn into an editable string, displayed in 'Hex' Display Style, and 0x0D populating the string.  This allows the dev to verify the value before turning it back into a iconic node again.


I think it could map to numeric constants, too.  If you have a numeric constant and type "pi", it becomes the pi constant, etc.


@Jim_Kring Dan_Lauber wrote:


I think it could map to numeric constants, too.  If you have a numeric constant and type "pi", it becomes the pi constant, etc.

How does one type the alpha characters "pi" into a numeric?


Trusted Enthusiast

You can type "pi" in a numeric. It won't accept it, but you can type it.


In a VI, you even get a numeric control's alpha characters from the NumText.text property. So alpha characters in numerics seem to be a pretty well established feature for numeric controls.


This doesn't mean it is easy to implement. It does mean there is a chance that it's easy to implement.

Proven Zealot

When you enter data into a numeric control, they accept a limited set of non-digit characters. That set could be expanded. Some existing examples:








And you can set the display format to have whatever characters you want.