Background Long IDs
Mark Waddingham
mark at livecode.com
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
group).
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,
Mark.
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.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the use-livecode
mailing list