Menu Buttons

[Pete]

The original code examples didn't have the && between menuPick and (line 3
of btn "Examples") - that was the real problem I saw, probably should have
made that clearer.  Personally, I've got into the habit of using dispatch
rather than send whenever possible just because the syntax lends itself to
much easier passing of parameters.

I think it's also worth commenting on setting the menuHistory to solve this
problem.  If a handler sets the menuHistory to it's existing value, no
menuPick message is generated.  I can't tell if that's significant to this
problem but good to be aware of.

Pete
Molly's Revenge <http://www.mollysrevenge.com>




On Tue, May 10, 2011 at 10:16 AM, Jim Ault <jimaultwins at yahoo.com> wrote:

> On May 10, 2011, at 9:43 AM, Pete wrote:
>
>  I might be wrong but I think the send commands, as you listed them, aren't
>> correct - I believe the message and it's parameters have to be one string.
>> So something like:
>>
>> send "menuPick aspirin" to button "Examples"
>>
>> or
>>
>> send "menuPick" && (line 3 of btn "Examples") to btn "Examples"
>>
>
>
> Pete, you are probably correct 'most of the time' and the reason is that
> most of the time the interpreter will use what it thinks you mean when it
> finds ambiguous syntax, and get it right.
>
> What this means is that to the interpreter...
>
> send menuPick && (line 3 of btn "Examples") to btn "Examples"
>
> could mean menuPick as a reserved word
> could mean menuPick as a variable
> or
> could mean "menuPick" as a string
>
> Hopefully you can see that you are leaving it up to the interpreter to know
> which you intend.
>
> send desiredKeyword  && paramVariable to btn "Examples"
> -- can vary depending on what the interpreter sees as
> --  desiredKeyword > {literal string, variable, reserved word}
>
> If it is seen as a reserved word, then it probably evaluates as an empty
> string.
> step 2  If it is seen as a variable container, then it evaluates the value
> of that variable.
> and step 3 in the decision tree is to assume it is a literal string.
>
> To be consistent and reliable, a programmer should always insure a literal
> string is used and arrives as the exact equivalent desired, including spaces
> and commas.
>
>>
>>  Hope this helps.
>
> Jim Ault
> Las Vegas
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>