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
