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
