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 > <firstname.lastname@example.org> 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 > email@example.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 firstname.lastname@example.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode