03-05-2009 03:59 PM - edited 03-05-2009 04:02 PM
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.
Solved! Go to Solution.
03-05-2009 08:34 PM
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...
03-05-2009 08:54 PM
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.
03-06-2009 03:31 AM
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...
03-06-2009 08:38 AM
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.
03-06-2009 08:56 AM
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 . 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
03-06-2009 09:12 AM
Ben wrote:bugus folder
I like that phrase. A bogus folder that was generated by a bug.
03-06-2009 10:17 AM
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?
03-06-2009 10:39 AM
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.
03-06-2009 11:01 AM
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