Trouble with 'there is a'

Ken Ray kray at sonsothunder.com
Fri Jan 27 10:42:18 EST 2012


> My real script did have two problem but they were quite different, and might be of interest.

I'm glad you brought these up - for others reading this there are some "best practices" to learn about these things:

> 1.  I had constructed a Windows-style path with "\" characters to fit in with a small VB script I wanted to run. This does work in some contexts, but not in this one: in normal circumstances (but not AFAICS in VB scripts) LC looks after the change from "/" to "\". I forgot that it was this path in the variable I was testing. It gave a strange result, but the obvious answer is "don't do it".

Right. If you *do* need to construct a "\"-delimited path for external use (for example, if you're creating a VBScript in LiveCode that you want to execute with "do … as VBScript"), then do your "/"-to-"\" conversions *just before* you use it, and do the conversion on a variable that's not going to be used again in that handler (like a temporary copy of a variable or one that is solely for the purpose of passing off to VBScript). For example:

   put specialFolderPath("desktop") & "MyFile.txt" into tFile
   -- maybe some other code goes here
   put replaceText(tFile,"/","\") into tTempFile
   -- construct VBScript using the tTempFile variable -- keeps tFile safe if you need to work with it later


> 2. The form of my 'if' condition was
> 
>  if there is not a file myPath &"/" & myfilename
> 
> it turns out that the 'there is no' statement doesn't construct the string before the evaluation: you have to ensure the evaluation of the string by putting it in brackets as in
> 
>  if there is not a file (myPath &"/" & myfilename)
> 
> There is an obscure warning about this in the dictionary: "The there is no operator is implemented internally as a function, and therefore has lower precedence than other operators". So it's a precedence issue.

One thing I've gotten into the habit of doing is to always surround concatenation and logic operations (especially those with symbols) in parentheses - apart from being more readable, it also saves headaches if the interpreter sees things differently than you intended. Examples:

   put ("This is" && "a test") into tVar
   if (tVar <> "") then …

For multiple logic operations it is even more important. Compare:

   if tVar > 100 and tFileName contains " " or tVar = 0 then

vs.

   if ((tVar > 100) and (tFileName contains " ")) or (tVar = 0) then


Just my 2 cents,

Ken Ray
Sons of Thunder Software, Inc.
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/	




More information about the use-livecode mailing list