LV2009 Connectivity > Utiities palette escape/unescape not reciprocal

[james brunner]

It seems like the unescape method always adds an extra \00 (%00) at the end of the string.

James

[RavensFan]

I think it's a bug.

You can open up the Unescape function as a subVI.  I copied the code to a regular VI so I can do highlight execution.  It searches the string for a % character, and converts the next two characters after that to the ASCII character.  Well, when it doesn't find a % character, the Scan from String function raises an error (which the execution mode of the original subVI ignores because Enable Automatic Error Handling is unchecked).  So what happens is there is no final %2x to find, the error is ignored, and the default value of the datatype is returned (a zero), and that is converted to the ASCII 0 character which is a null and appended to the end of the string.

Now maybe it is intended behavior to return a null terminated string.  But it isn't the cleanest bit of code to take what is essentially an error in the Scan from String function, ignore it, and allow the default behavior to put a \00 at the end of the string.

[james brunner]

I agree that it is likely a bug.  BTW, you can change the VI's execution properties to allow execution highlighting ("Allow debugging").

There's a similar (though not identically coded) VI distributed with the NI Internet Toolkit called "CGI Unescape HTTP Param.vi" that I believe does a better job.  The case for no "%" character match is handled explicitly.  Here is the pertinent piece of that VI's diagram:

James

[RavensFan]

---

@james brunner wrote:

BTW, you can change the VI's execution properties to allow execution highlighting ("Allow debugging").

---

Thanks for mentioning that.  It just wasn't jumping out at me that that checkbox was unmarked and was what was causing highlight execution and probing to be disabled.  It is a setting I have never felt the need to change from the default of being checked, so I don't pay much attention to it.

Hopefully someone from NI who reads this thread can chime in and say whether they agree this is a bug and log it as one if they do.  If it is, it should be a simple fix in the next version of LV.

[jareds]

Hi Guys,

Thanks for pointing this out!  This was reported to R&D (# 238868) for further investigation.  You can edit the VI to fix this by checking the return of the Match Pattern function for an empty string.  Thank you again for your feedback!

[james brunner]

I'd like to point out that a fix has NOT made it into LabVIEW 2010 (as of yet).

[jareds]

Hi James,

You are correct that the fix has not made it into LabVIEW 2010.  The investigation into this Corrective Action Request is ongoing, but you should be able to find when it has been fixed using the number in my previous post.

[TCPlomp]

What I find a little bit worrying is that this bug never is tracked by NIs quality control. It looks like there is no unit-test done on this VI.

The problem might be even bigger, since this VI is used throughout the NI SCC code. I will thouroughly check the upcoming beta of 2011 to see if it's fixed.

In the meantime I propose a code construct like this to fix the issue:

The other case is '-1' were the string outputs are set to 'Use Default if unwired' (and are unwired).

What I don't understand in the original code is the use of the Scan from string (which I suppose is slow compared to get number from hex-string), togheter with the I32 array to U8 to string hocus-pocus.

The only thing I'm not sure about is the 'Split String' I use speedwise.

Ton