Background Long IDs

Mark Waddingham mark at
Tue May 8 05:03:49 EDT 2018

On 2018-05-07 21:23, Richard Gaskin via use-livecode wrote:
> Brian Milby wrote:
>> The end goal is to enable a binary stack to have the scripts within
>> tracked via GitHub.  A closely related goal is to enable editing of
>> said scripts via an external editor.  Script only stacks are not the
>> way that I want to go for these projects (they are distributed as
>> stacks and used within the IDE as plugins).  I've got import/export
>> working and a directory watcher that will start an import when a file
>> is updated.  Unlike lcVCS, this does not attempt to do anything with
>> tracking the other parts of the stack, just the scripts.
> Ah, very cool.  Thanks.
> As for the inconsistent bg refs which started this thread, my first
> inclination is that since consistent absolute refs are critical, any
> differences in what "long ID" returns based on what card you're on (or
> where you're sitting, or what day of the week it is, or other factors
> that don't change the object being referred to) would be a bug, since
> it's counter to the design goal of "long ID".

At a rough guess, I'd say that the way shared groups are actually 
implemented is interferring with the collection of the long id.

A group can be shared or not shared (sharedBehavior), and if it is 
shared it can be a background (backgroundBehavior).

When you go to a card with a shared group, or (in most cases) reference 
a shared group against a card, the group is reparented to that card (a 
group can only ever have one parent at once). If the group is a 
background then the order of messages is switched (card first, then 

I suspect the computation of the long id is not looking at the shared 
behavior / background behavior properties and just interpreting the 
owner chain. However, there is a slight wrinkle in that without a card 
id reference in the long id, you aren't really getting a reference which 
is useful at runtime - any computation done with it would be relative to 
the current card of the stack the group is on.

So I wonder if really, if you do:

   get the long id of group "Shared" of card 1

Then it should return

   group id <id of shared group> of card <id of card 1> of stack ...

Regardless of its shared status - making it consistent with all other 
groups. After all you can always check the 
sharedBehavior/backgroundBehavior property in script to see if it is one 
of those.

Warmest Regards,


P.S. Of course, I think Ali attempted to clean this up before (from 
memory - in particular, parsing the card id context to greater depth in 
various parts of the engine) - but it broke lots of things unfortunately 

Mark Waddingham ~ mark at ~
LiveCode: Everyone can create apps

More information about the Use-livecode mailing list