Send and the context

Bob Sneidar bobsneidar at iotecdigital.com
Sat Feb 8 10:31:54 EST 2014 

Thanks Björnke. I decided on a different strategy of putting a function in the card script that gets the values of all the objects I need and returns them as an array. I don’t think being clever with the message path is going to be one of my foundational methodologies in the future. :-)

Bob


On Feb 8, 2014, at 03:25 , Björnke von Gierke <bvg at mac.com> wrote:

> You might be interested in the "call" command.
> 
> On 08.02.2014, at 07:34, Bob Sneidar <bobsneidar at iotecdigital.com> wrote:
> 
>> This may bore most of you to tears so please disregard if it doesn’t interest you. 
>> 
>> What I am attempting is to be able to get values from objects on a card that is not the current card, or even in the current stack, like fields and states of buttons, without enumerating the entire path to the objects themselves. This is because the card is designed to be portable, that is, to be placed into any stack. The first time you go to the Database Setup card, all the sqlYoga database connections will be initialized, connections tested, and then connections made. It also has some database utility functions I use. I’ll share it with the community when I am done shaking out all the dust mites. 
>> 
>> Now I do have a few globals I use, and could do everything with globals if necessary, but that seems messy to my mind. Also, globals prevent the card from working properly in multiple stack environments! I might have a Database Setup card in several different stacks, and they all need to behave discreetly. (This is why Stack Local variables would be HUGE!) 
>> 
>> That is the back story. Now there are times when I need to get the values of objects on the Database Setup card of the current stack without actually going to the Database Setup card itself (I might be in a substack and it might be modal for instance) so I inserted the script of a button with all the Database Setup handlers into the message path, and then “send” commands to it, so that statements like:
>> 
>> put field “fDBType” into theDBType — this field resides on the Database Setup card
>> 
>> would execute in the context of the Database Setup card. This threw Object Not Found errors, so I thought maybe it’s because the script was inserted into the message path. I then tried this with another button on the Database Setup card whose script was NOT inserted into the message path and got the same result! 
>> 
>> At that point I put in this handler into the script of the Database Setup card:
>> 
>> on test
>> put the short name of this card
>> end test
>> 
>> Whether I send or dispatch I get the current card of the current stack.
>> 
>> If however:
>> 
>> on test
>> put the short name of me
>> end test
>> 
>> I now get “Database Setup” whether I use send or dispatch! Well… that IS what I want I suppose. That prompted this thread. If this is the expected behavior, then I really do not understand at all what the dictionary means by “execution context”. I DID however find one other difference between send and dispatch: You can send a command but NOT a function! Dispatch works with commands AND functions. 
>> 
>> At any rate, it’s academic. I solved the problem by putting this handler in the Database Setup card script:
>> 
>> function getConnection theDBObject
>>  switch theDBObject
>>     case "primary"
>>        put the hilite of button "btndbPrimary" of me into aConnection ["enabled"]
>>        put (the backgroundcolor of button "btnPriConnected" of me is lightgreen) into aConnection ["connected"]
>>        put field "fPriDBType" of me into aConnection ["dbtype"]
>>        put field "fPriDBHost" of me into aConnection ["dbhost"]
>>        put field "fPriDBPort" of me into aConnection ["dbport"]
>>        put field "fPriDBName" of me into aConnection ["dbname"]
>>        put field "fpriDBUser" of me into aConnection ["dbuser"]
>>        put field "fPriDBPass" of me into aConnection ["dbpass"]
>>        break
>>     case "secondary"
>>        put the hilite of button "btndbSecondary" of me into aConnection ["enabled"]
>>        put (the backgroundcolor of button "btnSecConnected" of me is lightgreen) into aConnection ["connected"]
>>        put field "fSecDBType" of me into aConnection ["dbtype"]
>>        put field "fSecDBHost" of me into aConnection ["dbhost"]
>>        put field "fSecDBPort" of me into aConnection ["dbport"]
>>        put field "fSecDBName" of me into aConnection ["dbname"]
>>        put field "fSecDBUser" of me into aConnection ["dbuser"]
>>        put field "fSecDBPass" of me into aConnection ["dbpass"]
>>        break
>>  end switch
>> 
>>  return aConnection
>> end getConnection
>> 
>> Now my database back scripts can call this function, and because the button containing the back scripts exists on the same card, they execute in the context of that card. (Whew!) 
>> 
>> Bob
>> 
>> On Feb 7, 2014, at 09:02 , Mike Bonner <bonnmike at gmail.com> wrote:
>> 
>>> Ah k. I understand what you're saying now.
>>> 
>>> The OP points out that "put the short name of this card" is returning the
>>> current card (as per the dictionary, and the behavior in the OP matches
>>> this.)
>>> If things remain the same and the message is "sent" to the card itself
>>> (like it was in the OP) then the handler in the card can "put the short
>>> name of me" and it will work because the handler is executing in the card,
>>> but if the message is sent to an object on a card "the short name of me"
>>> will return the object name not the card name. So one would have to do
>>> something else to get the card name. (get the long name and parse, or go up
>>> the "owner" tree till you get there if there are groups involved)  So I
>>> guess the OP example is a bit silly since if you're sending to the card
>>> specifically you already know what it is and if you must, can pass it as a
>>> parameter as part of the send.
>>> 
>>> Curious now though, is there an easy way to get the owning card name of an
>>> object that is sent to without parsing or tree crawling?
>>> 
>>> 
>>> On Fri, Feb 7, 2014 at 9:07 AM, Mark Wieder <mwieder at ahsoftware.net> wrote:
>>> 
>>>> Mike-
>>>> 
>>>> Friday, February 7, 2014, 7:08:29 AM, you wrote:
>>>> 
>>>>> Its also probable I should have typed it clearer.. use "of me" instead.
>>>>> "This" refers to the current card of the default stack.
>>>> 
>>>> I'm not concerned about your use of "this" or "current". But "me" is
>>>> the object that generated the send or dispatch message. If you want
>>>> the message to end up going to the card, direct it to the card, not to
>>>> me.
>>>> 
>>>> If me sends or dispatches a message to me, me will get the message.
>>>> 
>>>> --
>>>> -Mark Wieder
>>>> ahsoftware at gmail.com
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>>>> 
>>> _______________________________________________
>>> 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
>> 
>> 
>> _______________________________________________
>> 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
> 
> 
> -- 
> 
> Use an alternative Dictionary viewer:
> http://bjoernke.com/bvgdocu/
> 
> Chat with other RunRev developers:
> http://bjoernke.com/chatrev/
> 
> 
> 
> _______________________________________________
> 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

More information about the use-livecode mailing list