Weird behaviour

[bottomleypotts]

I have a problem with winbatch. It does not appear not all numbers in a string can be converted correctly.

See the messages the following code produces. Can someone explain why the last number in each line is not being recognized as a number and a way around it in the immediate interim?

Code (winbatch) Select Expand


v=$"xxx,1,2
yyy,2,3
zzz,3,4$"

For i=1 to ItemCount(v,@LF)
   e=ItemExtract(i,v,@LF)

   a=Arrayize(e,`,`)

   m=``

   For j=0 to ArrInfo(a,1)-1
      m:=j:` `:IsNumber(a[j]):@CR
   Next j
   Message(i,m)
Next i


[bottomleypotts]

Just a follow up. Just noticed the extra space in the string before the @LF. Sigh!

[kdmoyers]

Yeah, when you use the multiline style strings (which are otherwise great) you get a surprising space at the end of each line.  It's no problem once you realize it's there. 

It's actually documented: "Note that when a script line is delimited by the carriage-return + line-feed combination, the carriage return is converted to a space and the line-feed character is retained."

[td]

Could be solved with this simple modfication

Code (winbatch) Select Expand

m:=j:` `:IsNumber(strTrim(a[j])):@CR

But as Kirby mentioned the trick is knowing the space is there.

[td]

If you happen to use WinBatch Studio to create and edit your scripts, you can change the settings to use line-feed instead of carriage-return + line-feed as the line terminator in your scripts. Select the "View" top-level menu and then "Options..." -> "File Types" tab -> select "WIL Files" from the "File" dropdown -> select the "LF" radio button in the "Line end" group box -> press the "OK" button.

Using this technique you don't ever have to worry about the extra space as long as you use WinBatch Studio to create and edit your scripts.