Is the tab key always a numtochar(9)? I am trying to load the itemdelimiter with a variable. When the variable is a 'tab', I am getting a error - 'Source is not a character'.
Would it be safe to use the following for a tab delimiter?
Put numtochar(9) into gDelimiter
set itemdelimiter to gDelimiter
Or is there a better way? The value of the delimiter may change...which is why I don't harcode it:
ie. set itemdelimiter to tab
Thanks for any help!
Warren
Using variable as a itemdelimiter
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 10049
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Tab is one of the supported constants. Used without quotes as a value, it means the same as numtochar(9).
So your example:
set itemdelimiter to tab
..should work just fine.
So your example:
set itemdelimiter to tab
..should work just fine.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Not wishing to put words into Richard's mouth, but I think he is saying that if you do:
Personally, I often use some of the 'non-printing' ASCII characters (around 30 in the code table) as delimiters. As it seems that these characters ('group separator', 'record separator', etc) have generally been forgotten, I can be pretty sure that they will not occur inside any text I am processing.
I only came across one glitch doing this, and it was in transferring a stack between Windows and OS X. Rev does some automatic characters translations between the different OS, and these characters caused problems.
I thought I'd entered it as a bug, but on checking the bug database I can't find the report.
then you will achieve what you desire.Put tab into gDelimiter
Personally, I often use some of the 'non-printing' ASCII characters (around 30 in the code table) as delimiters. As it seems that these characters ('group separator', 'record separator', etc) have generally been forgotten, I can be pretty sure that they will not occur inside any text I am processing.
I only came across one glitch doing this, and it was in transferring a stack between Windows and OS X. Rev does some automatic characters translations between the different OS, and these characters caused problems.
I thought I'd entered it as a bug, but on checking the bug database I can't find the report.