Background Long IDs

Brian Milby 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
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 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,
>
> 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
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



More information about the Use-livecode mailing list