I just glanced at this. Down at the very beginning, I noticed something odd. One cannot do anything with “the text" of a variable; that would not throw an error, but would always be empty, no?
Craig > On Jun 28, 2022, at 3:49 PM, Peter Bogdanoff via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Hi Bob, > > I need more detail how to word the command. No need to send in time, just how > to call that function on a card not in the message path. Thanks! > >> On Jun 28, 2022, at 12:12 PM, Bob Sneidar via use-livecode >> <use-livecode@lists.runrev.com> wrote: >> >> Send IF you need in time. Stupid spell correct. It cannot be me mistyping. >> >> Sent from my iPhone >> >>> On Jun 28, 2022, at 12:08, Bob Sneidar <bobsnei...@iotecdigital.com> wrote: >>> >>> Send in you need in time. Dispatch if you are not sure the handler exists >>> in the target. Dispatch will not throw an error if there is no handler. >>> >>> Sent from my iPhone >>> >>>> On Jun 28, 2022, at 11:05, Peter Bogdanoff via use-livecode >>>> <use-livecode@lists.runrev.com> wrote: >>>> >>>> Bob, >>>> >>>> This makes sense. >>>> >>>> I’m unclear as to how I would structure the command to call a function in >>>> a card that’s not in the message path. >>>> >>>> send … ? >>>> >>>> Peter Bogdanoff >>>> >>>>>> On Jun 28, 2022, at 8:34 AM, Bob Sneidar via use-livecode >>>>>> <use-livecode@lists.runrev.com> wrote: >>>>> >>>>> Your point brings up something that was discussed before on this list. >>>>> It's going to be cleaner in the long run to "compartmentalize" your >>>>> handlers so that a handler is not trying access objects that are not in >>>>> the message path, or belong to an object in the message path. A handler >>>>> should not if at all possible "reach out and touch" something on another >>>>> card. >>>>> >>>>> If you need to get or set something on a card other than the one in the >>>>> message path of the current handler, it's better to have a command or >>>>> function in the script of the target card. That way you can say: >>>>> >>>>> function returnTheText pFieldName >>>>> return the text of field pFieldName of me >>>>> end returnTheText >>>>> >>>>> If you DO need to have handlers working in a broader context, then when >>>>> calling the handler get the long id of the target card first and then >>>>> pass that in a parameter to the handler. >>>>> >>>>> For instance I have a handler called Extract which retrieves to values >>>>> for every object on a card with certain prefixes in their name like fld >>>>> or btn or menu. I pass the long id of the card they are on so that there >>>>> is never any confusion as in: >>>>> >>>>> function extract tParentCard >>>>> return the text of field 1 of tParentCard >>>>> end extract >>>>> >>>>> Bob S >>>>> >>>>> >>>>>>> On Jun 27, 2022, at 20:27 , Neville Smythe via use-livecode >>>>>>> <use-livecode@lists.runrev.com> wrote: >>>>>> >>>>>> If I write >>>>>> >>>>>> put the long id of field 1 of card 1 into tObject; put the text of >>>>>> tObject >>>>>> >>>>>> I get the text of field 1 of card 1, right ? Not necessarily. >>>>>> >>>>>> If field 1 of card 1 is in a shared group, then what I get is the text >>>>>> of field id something of card id whatever, where whatever is the id of >>>>>> the current card or maybe the first card containing the group. >>>>>> >>>>>> This is not actually a bug when you read the docs carefully but it >>>>>> certainly is a trap and in my case a major bug generator. It means this >>>>>> seemingly obvious way of obtaining the long id of an object (rather, in >>>>>> this case an instance of an object) cannot be used to uniquely identify >>>>>> it when getting its properties. >>>>>> >>>>>> The workaround is to replace card id (whatever) with card id (the id of >>>>>> card 1) in tObject; the properties of tObject returned are then the >>>>>> properties of the expected instance of the object. >>>>>> >>>>>> Sigh, a new version of nsScriptDatabase coming up. >>>>>> >>>>>> Neville >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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-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
