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 <[email protected]> wrote: > You might be interested in the "call" command. > > On 08.02.2014, at 07:34, Bob Sneidar <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> >>>> >>>> _______________________________________________ >>>> use-livecode mailing list >>>> [email protected] >>>> Please visit this url to subscribe, unsubscribe and manage your >>>> subscription preferences: >>>> http://lists.runrev.com/mailman/listinfo/use-livecode >>>> >>> _______________________________________________ >>> use-livecode mailing list >>> [email protected] >>> Please visit this url to subscribe, unsubscribe and manage your >>> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> _______________________________________________ >> use-livecode mailing list >> [email protected] >> 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 > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
