viewing invisible characters in variable watcher

[mattmaier]

Variable watcher is neat. It saves me what would be a lot of trouble trying to manually print the contents of my variables.

However, I've got a problem now where a random carriage return seems to be sneaking into one of the elements of an array. Carriage returns are invisible, so they don't appear in variable watcher.

Is there a way to tell variable watcher to display all of the characters, including the invisible ones like carriage return or new line? Kind of like how microsoft word has (or had) a view that would let you see all of the formatting commands like paragraph markers.

[dunbarx]

Hmmm.

I could be wrong, but I do not think so.

I thought the ability to display invisible and control characters was neat. Tabs appeared as right=pointing arrows, and you could see formatting issues at a glance. But even in that mode, returns still delimited lines, and all one got from the display was the appearance of that character representation (I think ASCII 194).

Arrays are displayed in the clear in the variable pane when debugging, and any returns would format as distinct line breaks. In that sense, you can "see" all the returns.

Any else actually know what they are talking about?

Craig Newman

[jacque]

If there are carriage returns in the variable, the value will have more than one line and a magnifying glass will appear to the right. Click it and a separate window will appear so you can see all the lines.

Other invisible characters may appear as small boxes, but I can't remember if that's consistent.

[mattmaier]

If there are carriage returns in the variable, the value will have more than one line and a magnifying glass will appear to the right.

Arrays are displayed in the clear in the variable pane when debugging, and any returns would format as distinct line breaks. In that sense, you can "see" all the returns.

That's more or less what I assumed as well, but the problem was that the returns would appear when the data was moved to a text field while still not appearing at the same time in the variable watcher.

From some other discussions it seems that returns are treated like an exception sometimes. They don't count as a char if you query the line, but they do count as a char if you query the field, for example. Since the point of variable watcher is to tell you what's going on inside your invisible data structures, it would be nice if it displayed all of the information in there, even if it wouldn't normally be visible.

Would that be a feature request or a bug report?

I got around the issue by adding a filter for returns on the previous step. Still not sure how they got in there, but after replacing them with empty the data displayed cleanly in a text field.

[jacque]

From some other discussions it seems that returns are treated like an exception sometimes. They don't count as a char if you query the line, but they do count as a char if you query the field, for example. Since the point of variable watcher is to tell you what's going on inside your invisible data structures, it would be nice if it displayed all of the information in there, even if it wouldn't normally be visible.

Would that be a feature request or a bug report?

The differences between lines and containers is an expected behavior when dealing with any delimiter. If you get an item or a line, LC returns the content of that chunk without including the delimiter. If you look at the entire container, then all delimiters are a part of the contents. For example, when getting item 2 of "red,blue,green" you would not likely want to receive "blue," (with comma), you are probably looking only for "blue". But if you get the entire container, you receive everything, commas and all.

The same holds in the variable watcher. If you are getting the content of an individual line, the return will not be there. If you are looking at the entire field content, then they will be. The same holds true for array elements; if there is more than one line in an element then you should see them. However, if the array is split by carriage returns, then the keys will not show returns because the variable watcher lists those as individual lines already.

I may be confused about what you're seeing, but it seems there's no bug here, it's just how LC works, and has since the inception of the "talk" languages 25+ years ago. If you saw something different, it would be good to get an example of the array you are using so we can see if there's a bug there or not.

[mattmaier]

I parsed a string that didn't involve any returns into an array
Then I un-parsed the array back into text
The variable watcher just showed the expected content in the element, but when the whole array was turned back into text one of the elements had a return in it, causing two lines where one was expected.

Thus, the question about how the variable watcher works. Since the point is to show you things you can't normally see so that you can tell exactly what's happening, it would make sense to render invisible characters too, since you can't see them.

It's not a question about my specific case, but about how exactly the variable watcher works. Like, maybe there's an option to see delimiters or something.

[jacque]

Could we see the relevant part of the script and some example text? I'd like to try it so I know what you're seeing.

[mattmaier]

I've got a field with this in it

Code: Select all

- key: 0
  next: 4
  start: [1, 3]
  end: [2, 4]
- key: 1
  type: state
  in: [2, 3]
  out: [4, 5]
  non: [3]
- key: 2
  type: change
  in: [1, 2]
  out: [5, 7]
  non: []
- key: 3
  type: note
  in: []
  out: []
  non: [1]

which gets parsed into an array

Code: Select all

 global platypus

on mouseUp
   put field "plain text" into rawText
   split rawText by "- "
   repeat for each key tKey in rawText
      split rawText[tKey] by (return & "  ") and (": ")
      repeat for each key tKey2 in rawText[tKey]
         if the char 1 of rawText[tKey][tKey2] is "[" then
            split rawText[tKey][tKey2] by ", "
            repeat for each key tKey3 in rawText[tKey][tKey2]
            replace "[" with "" in rawText[tKey][tKey2][tKey3]
            replace "]" with "" in rawText[tKey][tKey2][tKey3]
            --replace return with "" in rawText[tKey][tKey2][tKey3]
            end repeat
            end if
      end repeat
   end repeat
   
   --clean up--
   --since the string starts with a delimiter there's an empty first element
   delete variable rawText[1]
   --can't change key names, so just move to new array with proper names
   repeat for each key tKey in rawText
      put rawText[tKey] into platypus[rawText[tKey]["key"]]
   end repeat
   --remove working array
   delete variable rawText
  end mouseUp

then gets turned back into text and put in a different field

Code: Select all

global platypus

on mouseUp
   -- put the array in platypus[] into field output text
   -- metadata key and next
   put empty into field "output text"
   put "- key: 0" after field "output text"
   put return & "  next: " & platypus[0]["next"] after field "output text"
   
   -- metadata start links
   put return & "  start: [" after field "output text"
   if platypus[0]["start"] is not empty then 
      repeat for each key tKey in platypus[0]["start"]
         put platypus[0]["start"][tKey] & ", " after field "output text"
      end repeat
      -- the repeat structure leaves an extra ", "
      delete the last char of field "output text"
      delete the last char of field "output text"
   end if 
   put "]" after field "output text"
   
   -- metadata end links
   put return & "  end: [" after field "output text"
   if platypus[0]["end"] is not empty then 
      repeat for each key tKey in platypus[0]["end"]
         put platypus[0]["end"][tKey] & ", " after field "output text"
      end repeat
      -- the repeat structure leaves an extra ", "
      delete the last char of field "output text"
      delete the last char of field "output text"
   end if 
   put "]" after field "output text"
   
   -- the rest of the nodes
   repeat for each key tKey in platypus
      if tKey is not 0 then -- already handled 0 in the metadata section
         put return & "- key: " & platypus[tKey]["key"] after field "output text"
         put return & "  type: " & platypus[tKey]["type"] after field "output text"
         -- the in links
         put return & "  in: [" after field "output text"
         if platypus[tKey]["in"] is not empty then 
            repeat for each key tKey2 in platypus[tKey]["in"]
               put platypus[tKey]["in"][tKey2] & ", " after field "output text"
            end repeat
            -- the repeat structure leaves an extra ", "
            delete the last char of field "output text"
            delete the last char of field "output text"
         end if 
         put "]" after field "output text"
         --the out links
         put return & "  out: [" after field "output text"
         if platypus[tKey]["out"] is not empty then 
            repeat for each key tKey2 in platypus[tKey]["out"]
               put platypus[tKey]["out"][tKey2] & ", " after field "output text"
            end repeat
            -- the repeat structure leaves an extra ", "
            delete the last char of field "output text"
            delete the last char of field "output text"
         end if 
         put "]" after field "output text"
         --the non links
         -- ! the empty non attribute probably shouldn't be displayed in text, need to escape this
         put return & "  non: [" after field "output text"
         if platypus[tKey]["non"] is not empty then 
            repeat for each key tKey2 in platypus[tKey]["non"]
               put platypus[tKey]["non"][tKey2] & ", " after field "output text"
            end repeat
            -- the repeat structure leaves an extra ", "
            delete the last char of field "output text"
            delete the last char of field "output text"
         end if 
         put "]" after field "output text"
      end if
   end repeat
end mouseUp

when I comment out line 12 of the text-to-array code I get this as an output

Code: Select all

- key: 0
  next: 4
  start: [1, 3]
  end: [2, 4
]
- key: 1
  type: state
  in: [2, 3]
  out: [4, 5]
  non: [3
]
- key: 2
  type: change
  in: [1, 2]
  out: [5, 7]
  non: [
]
- key: 3
  type: note
  in: []
  out: []
  non: [1]

when I don't comment it out I get this

Code: Select all

- key: 0
  next: 4
  start: [1, 3]
  end: [2, 4]
- key: 1
  type: state
  in: [2, 3]
  out: [4, 5]
  non: [3]
- key: 2
  type: change
  in: [1, 2]
  out: [5, 7]
  non: []
- key: 3
  type: note
  in: []
  out: []
  non: [1]

[jacque]

That's helpful, thanks. The reason you can't see the carriage return is because there is only one line in that element, it just happens to end with a return. In this case, you're right, it would be helpful to see the invisible characters. Or at the least, it would be nice if the value window would open so that you could place the cursor to see if there was a CR at the end of the line.

The reason you're getting the spurious return, as far as I can see, is because of an incorrect usage of the split command. You can only split by a single character. For some reason when you split the third key by comma-space, the engine is inserting a carriage return, maybe because there are no commas in the data. There is incorrect usage of the split command in the first two keys as well, but (apparently) since the initial character does exist in the data, no spurious return is added.

If you use only a single character for the split commands, the problem goes away.

[dunbarx]

Jacque.

You can split data into an array with two delimiters, just as you can retrieve that array data back into the clear with those same two.

Given in fld 1:

aaa,bbb
ccc,eee
fff,ggg

Code: Select all

on mouseUp
   get fld 1
   split it by return and comma
   
   combine it by return and comma
   answer it
end mouseUp

Craig

[jacque]

Yes, two delimiters. But not two characters:

split data with ", " -- that's "comma space"

[dunbarx]

Oh, I see. I should have read more carefully. You cannot split by "don'tBePrecipitous"

Craig

[jacque]

You can, however, have a split by "headache". At least, my mother often told me she had a splitting headache. The reason was usually me.

[dunbarx]

I offer the following:

"Insanity is indeed inherited. You get it from your children"

Craig

[mattmaier]

You can only split by a single character.

If you use only a single character for the split commands, the problem goes away.

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

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
   
   repeat for each key tKey in testString
      put testString[tKey] after field "endField"
   end repeat
end mouseUp

The first split produces an array like this:
1,2
3,4
5,6
7,8
and a field like this
1,23,45,67,8

The other (commented) option work as I'd intuitively expect. Since I'm doing the same thing in this small test (splitting by ", " and then reading the array back out into a field) and no erroneous new-lines are showing up I'm not sure what you mean. Maybe there's something I didn't account for.