viewing invisible characters in variable watcher

[mattmaier]

You cannot split by "don'tBePrecipitous"

Yeah, LiveCode is interpreting that as a variable and throws out an error. Cuz it's not punctuation, maybe?

[dunbarx]

Now I am confused.

As Jacque pointed out, LC will throw an error if you try to split data by the string ", " (comma-space). It will compile, but not run. When you split by comma alone, you get the array:

Code: Select all

1  1
2  2
3   3
4  4
5   5
6  6
7   7
8  8

where the element associated with each key either has a space or not, depending on whether there was a space in each "item" of the original comma delimited text. In this instance, since you are simply splitting data with a single delimiter, the keys will be numerically and sequentially assigned to each element. Placing that two char string in a variable throws the same error. LC would not care whether the literal or the variable was used.

How did you get this to run?

The closest I can get to what you reported would be this:

   split testString by space and comma

But even that is not quite what you saw, and anyway goes back to ordinary syntax, that is, two separate delimiters, separated into distinct tokens by the use of "and".

Craig

[dunbarx]

You cannot split by "don'tBePrecipitous"

Yeah, LiveCode is interpreting that as a variable and throws out an error. Cuz it's not punctuation, maybe?

You have to learn not to take me too literally.

Anyway, go back to the real thread. Something is going on there...

Craig

[Simon]

You have to learn not to take me too literally.

I was also concerned that was the case...

Simon

[jacque]

I thought I understood what you meant, but it looks like splitting by ", " works exactly like it should.

Well, there's definitely something odd going on. Either multiple characters are an undocumented feature or there's a bug in the engine. It does appear that at least in LC 7.0 (where I'm testing this) you can indeed split by multiple characters.

That doesn't explain why your original script gets artificially-inserted carriage returns when using a trailing space in the split command, and it doesn't with only a single comma. So there's some glitch somewhere but I can't quite pin down what it is.

Someone who can read the LC source code might be able to find it, I'm not that talented. But I'm definitely curious.

[dunbarx]

In 6.6.2 the engine throws an error with more than one char as a delimiter.

Craig

[jacque]

In 6.6.2 the engine throws an error with more than one char as a delimiter.

Ah yes, so I'm not completely senile yet. Mattmaier must be using 7.0. I wonder if this is a side effect of the Unicode implementation where 2-byte characters are the norm, because I just tried to split by 3 characters ("abc") and I get the expected compilation error. The unusual result (spurious carriage returns) may also be related.

[dunbarx]

Jacque.

OOOH.

That was incisive, that two-byte unicode connect. Mattmaier, Is it so?

Surely Monte or Mark W. or even Mark W. will chime in?

Craig

[jacque]

I'm not sure if it's a bug or not, but I reported it anyway. RR can close it out if I'm wrong, but my gut says it isn't supposed to do that.

[dunbarx]

The way that arrays are created, in that they are a set of keys with one or more levels of associated elements. requires that these parts be delimited explicitly. You can create multilevel arrays directly:

Code: Select all

put "foo" into myArray[a][b][c][d][e]

But the 'split" command only goes down one level, a key and an associated element. Would it be a feature to be able to split further:

Code: Select all

split "tkey,element1,element2,element3" by comma and comma and comma

or

split "tkey,element1,element2,element3" by ",,,"

or

split "tkey,element1#element2,@element3" by ",#@"

Craig

[mattmaier]

Sorry, yes, I am indeed using 7.0.

So far, the number of characters used to "split" doesn't seem to matter, just the type of character. Three characters works just fine:

Code: Select all

on mouseUp
   put "1,2 , 3,4 , 5,6 , 7,8" into testString
   
   split testString by " , "
   
   --   split testString by ","
   
   --   put ", " into tDelimiter
   --   split testString by tDelimiter
   
   put empty into field "endField"
   repeat for each key tKey in testString
      put tKey & " " & testString[tKey] & return after field "endField"
   end repeat
end mouseUp

that produces this

Code: Select all

1 1,2
2 3,4
3 5,6
4 7,8

Code: Select all

   put "1,,,,,,,,,,2,,,,,,,,,,3,,,,,,,,,,4,,,,,,,,,,5" into testString
   
   split testString by ",,,,,,,,,,"

that produces this

Code: Select all

5 5
1 1
2 2
3 3
4 4

[dunbarx]

Hi,

This is all ground breaking stuff. I wonder if the v.7 release notes say anything about changes to the "split" delimiters.

Craig

[jacque]

Hi,

This is all ground breaking stuff. I wonder if the v.7 release notes say anything about changes to the "split" delimiters.

Craig

Well, it will. My bug report was just reclassified as a documentation bug. As of 7.0, split delimiters have no character limit. RR can't reproduce my 3 character error, I'll see if I can get them a recipe.

[dunbarx]

Well.

Then does that imply that the "split" command will form a multi-layer array, based on the number of chars that are included as delimiters? Sort of what I mentioned?

split "tkey,element1,element2,element3" by comma and comma and comma

or

split "tkey,element1,element2,element3" by ",,,"

or

split "tkey,element1#element2,@element3" by ",#@"

Craig

[jacque]

I don't think so. It just means you can use comma-space as a delimiter, or even "headache". The array produced is still only one dimension.