long id trap for the unwary

[Bob Sneidar]

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 <use-livecode at lists.runrev.com> 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