You might be interested in the "call" command. On 08.02.2014, at 07:34, Bob Sneidar <bobsnei...@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 <bonnm...@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 <mwie...@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 >>> ahsoftw...@gmail.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 > > > _______________________________________________ > 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 an alternative Dictionary viewer: http://bjoernke.com/bvgdocu/ Chat with other RunRev developers: http://bjoernke.com/chatrev/ _______________________________________________ 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
