Background Long IDs
brian at milby7.com
Tue May 8 11:19:15 EDT 2018
I opened a stack where the shared/BG groups are not on the first card and
immediately issued the following in the message box:
put the long id of group "BG1" of card 1 of stack "AutoScriptSaver"
put the long id of group "SG1" of card 1 of stack "AutoScriptSaver"
In both cases I get:
Error description: Chunk: can't find background
Digging a bit, the card chunk is evaluated against the stack and not the
background/shared group. So since the BG/SG is not on the first card, it
generates an error. If I find the relative card (2 or 3 in this case) and
use that, it works. So to get a known consistent long ID for a
background/shared group, it will need to be built manually (or ensure that
every card is visited first).
I'm traversing every object in a stack with a script. My goal was to avoid
processing background/shared groups more than once. I capture a list of
shared groups and when looping on the objects on a card I check the list.
If the object is a shared group, then I skip it.
Relevant code is in exportStackScripts and exportChildContolScripts
On Tue, May 8, 2018 at 4:03 AM, Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:
> 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,
> 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
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode