Re: long id trap for the unwary
So the *actual* long id reference to any object looks something like: field id 1388156 of group id 1388155 of group id 1388175 of card id 1002 of stack "/Users/bobsneidar/Documents/Livecode Projects/Forms Generator 8/Forms Generator 8.livecode" If you don't provide all of that as a reference, then it's up to the engine to "fill in the blanks." That means you can say something like "field 1 of card 1" or "field 1 of stack myStack" or "field 1 of group 1" and you get what you expect. But when working with multiple stacks THAT depends on what is the topStack and currentCard, which can vary depending on whether or not you are actually opening the substacks and what they are opened as (modal, pallette, drawer etc.) Relative References are a great feature, making coding much simpler, but as you have seen it can also be a "trap" when working with multiple cards or stacks. To ensure you don't fall into it, it may be better for you to not leave it up to the engine, but to provide the full path to your objects. Bob S > On Jun 28, 2022, at 18:38 , Neville Smythe via use-livecode > wrote: > > No crashes or errors, I just didn’t get back the data I expected. > > Does it really have anything to do with message paths? > > I just expected > >the long id of field1 of card 1 > > to do what it says, that is, to return a specifier to (the instance of) field > 1 on card 1. At the time I was iterating through all substacks and controls > in a stack and wanted a specifier which would work for substacks as well as > objects so the long id was the natural choice. > > I understand why the long id of a group has to contain a reference to the > current card or the first card containing the group, but in this case I am > actually specifying the card reference I want, so it *could* return what I > expected, it just doesn’t. Tough cheese. (Oops, I mentioned c…..) > > > 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
Re: long id trap for the unwary
Neville. I know this thread has been broken into parts, but what exactly is your question? I made two stacks, The first with a button on it, and this in its script: on mouseup put the long id of field 1 of card 1 of stack "untitled 3" into fieldID put the long ID of the owner of fieldID into groupID put the owner of groupID into ownerID end mouseup The second stack (untitled 3) has a field that has been grouped. You get, in the SE, three pieces of information in those three variables. What does this do for you? Craig > On Jun 28, 2022, at 9:38 PM, Neville Smythe via use-livecode > wrote: > > No crashes or errors, I just didn’t get back the data I expected. > > Does it really have anything to do with message paths? > > I just expected > >the long id of field1 of card 1 > > to do what it says, that is, to return a specifier to (the instance of) field > 1 on card 1. At the time I was iterating through all substacks and controls > in a stack and wanted a specifier which would work for substacks as well as > objects so the long id was the natural choice. > > I understand why the long id of a group has to contain a reference to the > current card or the first card containing the group, but in this case I am > actually specifying the card reference I want, so it *could* return what I > expected, it just doesn’t. Tough cheese. (Oops, I mentioned c…..) > > > 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
RE: long id trap for the unwary
No crashes or errors, I just didn’t get back the data I expected. Does it really have anything to do with message paths? I just expected the long id of field1 of card 1 to do what it says, that is, to return a specifier to (the instance of) field 1 on card 1. At the time I was iterating through all substacks and controls in a stack and wanted a specifier which would work for substacks as well as objects so the long id was the natural choice. I understand why the long id of a group has to contain a reference to the current card or the first card containing the group, but in this case I am actually specifying the card reference I want, so it *could* return what I expected, it just doesn’t. Tough cheese. (Oops, I mentioned c…..) 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
Re: long id trap for the unwary
Klaus. You are correct; I missed that the “long iD” was used, and that expression includes the work “field”. LC can then use that as a valid reference. Craig > On Jun 28, 2022, at 5:38 PM, Bob Sneidar via use-livecode > wrote: > > You can find the definition of both send and dispatch in the dictionary. > > So an example of Dispatch being called from a card of a substack would be: > > put the long id of me into tParentCard > dispatch extract to card "Main" of stack "Forms Generator" with tRecordA, > tParentCard, tExclusions > > > -- if however extract is in the message path for everything, such as in a > library or back/front script, dispatch is not needed > -- but there's nothing wrong with using it > extract tRecordA, tParentCard, tExclusions > > > -- aRecordData is an array you want to populate with the field contents of > pParentCard > -- pParentCard is the long id of the target card containing field, button and > menu objects > -- pExclusions is a comma delimited list of object names you want to pass over > > on extract @aRecordData, pParentCard, pExclusions > -- store object values in aRecordData > put the text of field "fldCustomerName" of pParentCard into aRecordData > ["customername"] > put the hilited of button "btnActive" of pParentCard into aRecordData > ["active"] > put the label of button "mnuCategories" of pParentCard into aRecordData > ["category"] > ... > -- no need to return anything in this example because aRecordData is passed > by reference > end extract > > Bob S > > >> On Jun 28, 2022, at 12:49 , Peter Bogdanoff via use-livecode >> 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! >> > > > ___ > 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
Re: long id trap for the unwary
You can find the definition of both send and dispatch in the dictionary. So an example of Dispatch being called from a card of a substack would be: put the long id of me into tParentCard dispatch extract to card "Main" of stack "Forms Generator" with tRecordA, tParentCard, tExclusions -- if however extract is in the message path for everything, such as in a library or back/front script, dispatch is not needed -- but there's nothing wrong with using it extract tRecordA, tParentCard, tExclusions -- aRecordData is an array you want to populate with the field contents of pParentCard -- pParentCard is the long id of the target card containing field, button and menu objects -- pExclusions is a comma delimited list of object names you want to pass over on extract @aRecordData, pParentCard, pExclusions -- store object values in aRecordData put the text of field "fldCustomerName" of pParentCard into aRecordData ["customername"] put the hilited of button "btnActive" of pParentCard into aRecordData ["active"] put the label of button "mnuCategories" of pParentCard into aRecordData ["category"] ... -- no need to return anything in this example because aRecordData is passed by reference end extract Bob S > On Jun 28, 2022, at 12:49 , Peter Bogdanoff via use-livecode > 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! > ___ 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
Re: long id trap for the unwary
Hi Craig, > Am 28.06.2022 um 22:27 schrieb Craig Newman via use-livecode > : > > 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? no, if the variable contains a valid description of a field control. This works as advertized: ... put the long ID of fld 1 into tField put the text of tField ... Hope I understood you correctly. > Craig Best Klaus -- Klaus Major https://www.major-k.de https://www.major-k.de/bass kl...@major-k.de ___ 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
Re: long id trap for the unwary
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 > 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 >> 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 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 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 >> 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 >>> 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:
Re: long id trap for the unwary
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 > 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 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 >>> 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 > 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 >> 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
Re: long id trap for the unwary
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 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 >> 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 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 > 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
Re: long id trap for the unwary
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 > 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 >> 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 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
Re: long id trap for the unwary
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 > 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 >> 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
Re: long id trap for the unwary
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 > 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
