Re: Unexpected "word" parsing

Thx richard. Saw a post by you that mentioned it, I think it'll do what I need, thanks! I'm looking for a way to do it on windows too, have been trying to find out if it can be done with vbscript using setwindowpos() but haven't found the right info yet. If it can be done in vbscript, its likely

Re: Unexpected "word" parsing

Hi Mike, I think you were looking at the dictionary entry for "words" - the definition for "word" is where it mentions the return/tab. Pete lcSQL Software Home of lcStackBrowser and SQLiteAdmin

Re: Unexpected "word" parsing

If you're doing this on Linux you can install wmctrl and have shell control over window z-order and much more. -- Richard Gaskin Fourth World Systems Software Design and Development for Desktop, Mobile, and Web

Re: Unexpected "word" parsing

For natural-language words v7's Unicode routines should handle things well. For parsing LiveCode expressions try using the "token" chunk type. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web _

Re: Unexpected "word" parsing

It's not quite as straightforward as that since strings within double quotes are supposed to be recognized as words too. I'm fine with the way it works but the dictionary needs a few more words to explain that strings in quotes also need to have space/return/tab around them to qualify as words. P

Re: Unexpected "word" parsing

>From the 6.6.2 dictionary, though that line doesn't mention tab and return. Its just not handling quoted parts of a string very well it seems. Summary: Used with the sort command, number function, and is among and is not among properties to designate space-delimited or quoted parts of a string.

Re: Unexpected "word" parsing

If that is the case, then word 1 return the correct value, word 2 is incorrect. Word boundaries are spaces and there are no spaces so word 1 *should* be the whole string and word 2 should be empty. Bob S On Dec 5, 2014, at 13:42 , dunb...@aol.com wrote: word 1 of a str

Re: Unexpected "word" parsing

Yes, my tests were in the message box. Not that a big deal now I know what it does. Seems that the presence of a space/tab/return word delimiter overrides the presence of a quoted string within those delimiters. Off to make a dictionary note. Pete lcSQL Software Home of l

Re: Unexpected "word" parsing

On 12/5/2014, 3:19 PM, Peter M. Brigham wrote: myProps["cProp"] word 1 -> myProps["cProp"] word 2 -> "cProp"]. Also in the messagebox, if you ask for word 3 or word 4 or word 63 of that string, you get "cProp"] as well, so there's something screwy about using the messagebox for this. But in a bu

Re: Unexpected "word" parsing

Hi. In 6.7 OS (10.9), word 1 is the whole string, word 2 is empty. Craig -Original Message- From: Peter Haworth To: How to use LiveCode Sent: Fri, Dec 5, 2014 1:28 pm Subject: Unexpected "word" parsing word 1 of a string like myProps["cProp"] returns the

Re: Unexpected "word" parsing

On Dec 5, 2014, at 1:26 PM, Peter Haworth wrote: > word 1 of a string like myProps["cProp"] returns the whole string. Word 2 > returns"cProp"] > > Since cProp is enclosed in double quotes I was expecting: > > word 1 --> myProps[ > word 2 --> "cProp" > word 3--> ] > > This is with LC 6.6.2/OSX.

Unexpected "word" parsing

word 1 of a string like myProps["cProp"] returns the whole string. Word 2 returns"cProp"] Since cProp is enclosed in double quotes I was expecting: word 1 --> myProps[ word 2 --> "cProp" word 3--> ] This is with LC 6.6.2/OSX. Pete lcSQL Software Home of lcStackBrowser