What he said. ;-)
On Jan 27, 2012, at 7:42 AM, Ken Ray wrote:
>> 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: k...@sonsothunder.com
> Web Site: http://www.sonsothunder.com/
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
