LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Odd Shared Variable Dialog Box message

Solved!
Go to solution

I came across some odd behavior in the dialog box while I was created a new shared variable.

 

As I was typing in the name, I kept see a warning pop up in the dialog.  It would come and go as typed.  I figured out that whenever I typed a space, and thus it was temporarily the last letter in the SV name, the warning popped up.  Type the next letter, the warning would go away.  You can see the space ending the name right before the cursor in the top picture, and the name ending with a normal character in the bottom picture.

 

Now it is logical to me that ending a shared variable name with a space would be a bad practice, and should be warned against.  But the warning never actually states that you can't end with a space.  To be more precise, it says you can't have the slash code \s in the variable name.  Now I am not actually entering slash codes, but I am entering spaces.  And they seem to work just fine in the variable name, just not if it is the last character.

 

It just seems to be a mismatch between what the warning says, and what you can and can't do.

 

Can you have spaces in the SV name?  By my experience you can.

Also, this in in LV 8.6 on an XP SP3 machine.

 

Message Edited by Ravens Fan on 03-05-2009 05:02 PM
Message 1 of 11
(3,817 Views)

The error message is certainly messed up. Personally I think a much more rational behavior would be to forget the warning altogether and have LV simply trim of any trailing spaces before accepting the name.

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 11
(3,794 Views)

Thanks Mike,

 

I think best behavior would be that if trailing spaces are invalid (as they probably should be), the error message should say so clearly. If the program was going to do something like trim the spaces, it should warn me about rather than just doing it.  But only pop up with a warning or error dialog when you hit hit the OK button.  The flickering of the onscreen message error as you are typing just seems to be a bad user interface practice.

 

And if spaces are allowed within the variable name (as it seems like they are because it has worked for me), then the part about the \s implies that spaces aren't allowed (unless somehow you can have a \s code that is different from a space) just seems to be wrong.

 

Hopefully, someone from NI will chime in and either confirm this is unwanted behavior, or clearly explain why this behavior is correct.

0 Kudos
Message 3 of 11
(3,791 Views)

mikeporter wrote:

Personally I think a much more rational behavior would be to forget the warning altogether and have LV simply trim of any trailing spaces before accepting the name.


Also, the leading space should be trimmed, IMO...

- Partha ( CLD until Oct 2027 🙂 )
0 Kudos
Message 4 of 11
(3,770 Views)

parthabe wrote:

mikeporter wrote:

Personally I think a much more rational behavior would be to forget the warning altogether and have LV simply trim of any trailing spaces before accepting the name.


Also, the leading space should be trimmed, IMO...


Of course, definitely.Smiley Happy

0 Kudos
Message 5 of 11
(3,758 Views)

Related bug:

 

When writing an automatic archive operation for LV DSC I made a typo (what Ben a typo?) that resulted in a trailing space in a folder name Smiley Mad. The DSC Archive created the folder with the trailing space OK but was not able to access it since it had a trailing space. Windosw would not even let me delete the bugus folder! I ended up haveing to write a VI to delete the folder.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 6 of 11
(3,755 Views)

Ben wrote:

 bugus folder


I like that phrase.  A bogus folder that was generated by a bug.Smiley Very Happy

Message 7 of 11
(3,751 Views)

Thanks for the feedback guys!  I have gone ahead and filed a CAR on this issue including your suggestions. 

 

Ravens Fan, I have had the same experience with shared variables in that you can include spaces in the name, just not at the end. 😉

 

Ben, which VI did you use to create your bogus folder? Was this a specific DSC VI or just the generic Create Folder VI? 

ColeR
Field Engineer
0 Kudos
Message 8 of 11
(3,739 Views)
Solution
Accepted by topic author RavensFan

Thanks.  Please post the CAR ID# to the thread once you have it, then I'll put a link on the bug thread.

 

Just to clarify, I see basically three issues.

 

1.  The error message is incorrect in that spaces are allowed within the shared variable name, but the error in a somewhat unclear way says they aren't.

2.  Spaces at the beginning or end of the shared variable I believe should not be allowed, but Ben might have an instance where he "backdoored" one in there.

3.  User interface nuisance.  If spaces aren't allowed at the end of the SV, there is no need for a flashing error message on screen that pops up anytime you end a word with a space before you have the next word started.  The error message should really only popup once you've clicked OK to save the variable.

0 Kudos
Message 9 of 11
(3,736 Views)

ColeTrain wrote:

...

 

 

 

Ben, which VI did you use to create your bogus folder? Was this a specific DSC VI or just the generic Create Folder VI? 


The CAR for that bug was "105656".

 

The desription for that CAR was "Create DB while specifying path with space on end creates illegal Windows directory".

 

It supposed to create then put then put hte data files in the specified folder. It does the create but has trouble putting the data in the folder.

 

Ben

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 10 of 11
(3,721 Views)