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