problem with matchText

Got a LiveCode personal license? Are you a beginner, hobbyist or educator that's new to LiveCode? This forum is the place to go for help getting started. Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller

Post Reply
Newbie4
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 332
Joined: Sun Apr 15, 2012 1:17 am
Contact:

problem with matchText

Post by Newbie4 » Mon Jun 04, 2012 4:27 am

I am having trouble with the matchText function.
The first if statement works but the second one doesn't. Am I using it wrong?
I want to check if the first letter of the first word is any of the following: ABCDabcd

Code: Select all

 put char 1 of word 1 of thisLine into xchar
                   if xchar = "A" then
                      beep
                   end if              
                  if  matchText(xchar,"ABCDabcd") then
                      beep
                  end if
I tried it the other way:

Code: Select all

 if matchText("ABCDabcd",xchar) then 
and got the following error:
button "BCreate": execution error at line 47 (matchChunk: error in pattern expression) near "bad escape sequence", char 19
I tried checking if xchar is not empty but that did not fix it.

Am I going down a false path?
Should I be doing this another way?
Cyril Pruszko
https://sites.google.com/a/pgcps.org/livecode/
https://sites.google.com/a/setonhs.org/app-and-game-workshop/home
https://learntolivecode.com/

sturgis
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 1685
Joined: Sat Feb 28, 2009 11:49 pm

Re: problem with matchText

Post by sturgis » Mon Jun 04, 2012 5:42 am

Matchtext uses regular expressions for its matching.

if matchText(xchar,"^[ABCDabcd]") then --- In this line, xchar is the string being checked. Then the expression used for the check: ^ means starting at the beginning of the line. [] defines a set, so any of the chars in the set at the beginning of the string in xchar will be a match.

Now, the way you're doing it, grabbing the first char of the first word, you don't really need the ^ but if you were just checking the whole line (and knew that there are no preceeding spaces which would require a more complex regular expression) you could pass the whole string to the regular expression.

So if you had these lines in a variable named myVariable:

Apple Slices are Sour
Big Dogs Run Fast
Zebra Stripes give Strength

You could do this..

Code: Select all

repeat for each line tLine in myVariable
 if  matchText(tLine,"^[ABCDabcd]") then --check for match
    put tLine & return after tNewLines -- if match, add the line to a new variable. 
end if
end repeat
delete the last char of tNewLines --remove the trailing return
put tNewLines into msg --displays the matching lines in the message box. 
EDIT: Its probably easier to do it without matchtext anyway.
Since you're separating out the first char you can do something like this..

Code: Select all

if tChar is among the chars of "abcd" then --should not be case sensitive so only abcd need to be checked.
 ==do whatever for the match
else
-- do whatever for the non-match
end if

Newbie4
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 332
Joined: Sun Apr 15, 2012 1:17 am
Contact:

Re: problem with matchText

Post by Newbie4 » Mon Jun 04, 2012 12:47 pm

Thank you, you were really helpful. I learned a lot from your reply not only for now but for later too.

Your reply brings up another question: What is the difference between putting a return and putting a linefeed at the end of the line. Does it matter? Will one work under Windows and Mac computers or do they both methods always work on all platforms?
Cyril Pruszko
https://sites.google.com/a/pgcps.org/livecode/
https://sites.google.com/a/setonhs.org/app-and-game-workshop/home
https://learntolivecode.com/

sturgis
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 1685
Joined: Sat Feb 28, 2009 11:49 pm

Re: problem with matchText

Post by sturgis » Mon Jun 04, 2012 1:22 pm

return, cr, lf, linefeed are all synonyms and refer to ascii 10. They are interchangeable. As mentioned in the quote below return is in reality ascii 13, but internally lc uses ascii 10 for all the synonyms.

crlf is ascii 13 & ascii 10.

from the dictionary:
The return constant is a synonym for linefeed. This is different from some other languages, in which return is equivalent to the carriage return character (ASCII 13, Control-M). For most purposes, Revoluton translates the linefeed constant and its synonyms into the appropriate end-of-line character for the current operating system. However, you should keep this nuance in mind when processing data from another system, which LiveCode has not translated: return is not ASCII 13.

The line feed character is the standard end-of-line delimiter on Unix systems. The end-of-line delimiter for Mac OS systems is a carriage return, and the end-of-line delimiter for Windows systems is a carriage return followed by a line feed. Internally, LiveCode always uses a line feed to end lines.

Note: If you specify text mode with the open driver, open file, or open process commands, LiveCode translates line feed characters to the appropriate end-of-line marker for the current platform before writing data, and translates the current platform's end-of-line delimiter to a line feed after reading data. If you specify binary mode with these commands, LiveCode does not perform this automatic translation. Likewise, if you put data into a file URL or get data from it, end-of-line translation is performed, but not if you put data into or get data from a binfile URL.
So as to your question, there isn't any difference when used internally in lc. If you use text mode to write to a file LC puts the correct end of line markers for the os. If you are on windows and writing as binary rather than text (or put URL "binfile:filename") then on windows crlf would be the way to go (if I read the stuff in the dictionary correctly.)

Hopefully the quote and my too early in the morning reply hit the answer.

Post Reply