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 https://github.com/bwmilby/lc-misc/blob/master/ScriptTracker/ScriptTracker_Scripts/stack_ScriptTracker_button_id_1003.livecodescript Thanks, Brian On Tue, May 8, 2018 at 4:03 AM, Mark Waddingham via use-livecode < use-livecode@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, > > 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 > _______________________________________________ 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