Re: Background Long IDs

[Brian Milby via use-livecode]

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  of card  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

Re: Background Long IDs

[Mark Wieder via use-livecode]

On 05/08/2018 02:03 AM, Mark Waddingham via use-livecode wrote:

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).


Ick. Would it maybe make more sense to implement background groups as 
behavior objects? And that way not have to 'reparent' or change the 
message path?


--
 Mark Wieder
 ahsoftw...@gmail.com


___
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

Re: Background Long IDs

[Mark Waddingham via use-livecode]

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  of card  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

Re: Background Long IDs

[Brian Milby via use-livecode]

Not by the engine. There may be a better way, but the code is in button
1003. _getObjectLongName starts on line 421. I built the long ID on line
171.
On Mon, May 7, 2018 at 2:24 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> 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".
>
> Was that resolved in a way that would illuminate me?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> 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

Re: Background Long IDs

[Richard Gaskin via use-livecode]

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".


Was that resolved in a way that would illuminate me?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: Background Long IDs

[Brian Milby via use-livecode]

I've pushed an initial version to GitHub:
https://github.com/bwmilby/lc-misc/tree/master/ScriptTracker

The code is also there with the stack so it can be viewed online without
downloading the stack.  The code was exported from itself, so you can see
how it constructs the exports.  If you enable the Automatic File Import,
then it will notice changes to the exported files and import them back to
the stack (can't edit itself though).  Don't really know about performance
yet.  Devolution exports 112 files which takes ~450ms on my machine.

Thanks,
Brian

On Sun, May 6, 2018 at 10:46 PM, Brian Milby  wrote:

> Could be where it is being referenced.  From the message box:
> put the long id of background id 1020 of stack "AutoScriptSaver"
> Returns:
> bkgnd id 1020 of stack "/Users/milby/Desktop/AutoScriptSaver.livecode"
> Until after I visit the card, when it changes to:
> group id 1020 of card id 1025 of stack "/Users/milby/Desktop/
> AutoScriptSaver.livecode"
> This was in LC 8.1.9
> The stack uses files(folder, type) so it doesn't work in 8.
>
> On Sun, May 6, 2018 at 9:20 PM, dunbarx via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Hi.
>>
>> Maybe I am not building this correctly.  I made a new stack of five
>> cards. I
>> placed a BG group on card 3. It has ID 1005.
>>
>> On card 1 in a button script:
>>
>> on mouseUp
>>  put the long id of background ID 1005 of this stack into fld 2
>> end mouseUp
>>
>> In new sessions, whether I visit card 3 or not, I always get "group ID
>> 1005
>> of "
>>
>> Never "bkgnd ID 1005 of ..."
>>
>> LC 8.1.7
>>
>> Craig Newman
>>
>>
>>
>> --
>> Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-
>> User-f278306.html
>>
>> ___
>> 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

Re: Background Long IDs

[Brian Milby via use-livecode]

Could be where it is being referenced.  From the message box:
put the long id of background id 1020 of stack "AutoScriptSaver"
Returns:
bkgnd id 1020 of stack "/Users/milby/Desktop/AutoScriptSaver.livecode"
Until after I visit the card, when it changes to:
group id 1020 of card id 1025 of stack
"/Users/milby/Desktop/AutoScriptSaver.livecode"
This was in LC 8.1.9
The stack uses files(folder, type) so it doesn't work in 8.

On Sun, May 6, 2018 at 9:20 PM, dunbarx via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi.
>
> Maybe I am not building this correctly.  I made a new stack of five cards.
> I
> placed a BG group on card 3. It has ID 1005.
>
> On card 1 in a button script:
>
> on mouseUp
>  put the long id of background ID 1005 of this stack into fld 2
> end mouseUp
>
> In new sessions, whether I visit card 3 or not, I always get "group ID 1005
> of "
>
> Never "bkgnd ID 1005 of ..."
>
> LC 8.1.7
>
> Craig Newman
>
>
>
> --
> Sent from: http://runtime-revolution.278305.n4.nabble.com/
> Revolution-User-f278306.html
>
> ___
> 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

Re: Background Long IDs

[dunbarx via use-livecode]

Hi.

Maybe I am not building this correctly.  I made a new stack of five cards. I
placed a BG group on card 3. It has ID 1005.

On card 1 in a button script:

on mouseUp
 put the long id of background ID 1005 of this stack into fld 2 
end mouseUp

In new sessions, whether I visit card 3 or not, I always get "group ID 1005
of "

Never "bkgnd ID 1005 of ..."

LC 8.1.7

Craig Newman



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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

Re: Background Long IDs

[Brian Milby via use-livecode]

@Mark, same as before.  If the card has been visited then it starts with
group, if not it starts with bkgnd.

@Richard, probably more than you asked, but this is the project in a
nutshell...

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.

Part of each file that I export includes a header with a "Script"
declaration (so they are actually valid livecodescript files).  I also
include the long ID and long name in the header as a comment.  For
backgrounds, I list all cards that contain the background.  If the object
has a behavior, then that is listed.  Objects with a behavior and no script
are also exported for the header.  The idea is that from any script file,
you can easily know what other script files are in the message path.  The
files are named by stack, object type, and ID.  I'm using an MD5 hash of
the script (including the generated header) to detect in IDE script
changes.  I'm using file modification times to track external changes.
Eventually I'll probably start using IDE messages to know about script
changes within the IDE to trigger updates.  I'll also connect the open
stack and save stack messages.

Due to the need to have a consistent file name, I decided to code my own
handler to return my version of a long name/ID for backgrounds.  I have to
detect groups that don't have a name set (since I then need to use the
ID).  I already know that the ID is for a background when I'm building the
long ID so that one was easy.  When I get to where I need the long name, I
look at the first word of the long ID and go from there (if it isn't bkgnd,
then just have the engine return it).

The exporter does a diff for each export to allow for tracking of changes
without using Git (one file per export).  My thought there is more of a
short history so I can see what I changed between saves.  It is also a kind
of safety net to allow me to back track if something didn't import like I
thought it should.

I'm sure an inevitable "why" would be asked, so I'll try answer that now.
In the IDE, the list of open stacks includes all script only stacks as
well.  If I scriptify a plugin that doesn't use "rev" named stacks, then
every object now shows as a user stack.  I can't see how having dozens or
hundreds of entries in the stack list would be good for performance.  So,
the first reason is to have text file versions of the scripts without
adding to the IDE list of open stacks.  The second reason is mentioned
above - distribution.  Having all of the code self-contained in a single
file makes moving it around much easier (this is for stacks, not compiled
applications).

I am close to being able to let others look at the project.  Initially it
will just tackle a single mainstack, but eventually I want to use it as a
plugin that can watch any number of stacks.  My intent is to put this up on
GitHub - where the scripts will be easily viewable online but the actual
stack will be a single file download.

Thanks,
Brian

On Sun, May 6, 2018 at 1:55 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Brian Milby wrote:
>
>  > I'm working on a script exporter...
>
> What do you do with the exported scripts?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> 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

Re: Background Long IDs

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> I'm working on a script exporter...

What do you do with the exported scripts?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: Background Long IDs

[Mark Wieder via use-livecode]

On 05/05/2018 05:37 PM, Brian Milby via use-livecode wrote:

put the long id of background ID tObjectID of tStackLongID into
tObjectLongID


What do you get if you instead try

put the long id of control ID tObjectID of tStackLongID into
tObjectLongID

--
 Mark Wieder
 ahsoftw...@gmail.com

___
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