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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
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

Reply via email to