Confirming a thing about IDs

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Confirming a thing about IDs

Geoff Canyon via use-livecode
I had never tried this before. It seems to work, but I figured I'd run it
by the list, both as a way of confirming and informing.

Is it accurate that

<type> id <id> of stack "<stack name>"

is a complete and unique identifier for any control? (with the exception
for fields noted below)

For example, suppose there is a button in a group in a group that is a
background in stack "untitled 1". Further, suppose that background is not
placed on the current (or any) card in stack "untitled 1". Then the long id
of the button might be:

button id 1003 of group id 1004 of bkgnd id 1006 of stack "Untitled 1"

But, for example, this returns true:

put there is a button id 1003 of stack "untitled 1"

And as far as I know, there will never be any other button with id 1003 in
that stack. So

button id 1003 of stack "untitled 1"

is a unique and permanent id for that button, no matter what card, group,
or background it is in/on or not.

Is this correct? (mind blown if it is)

And of course I recognize that in the unique(?) case of a field with
sharedText set to false, the rest of the id could matter as far as the
htmlText, text, and rtfText are concerned. I just tested, and it seems that
in that case the groups are still irrelevant, and an ID like

put the text of fld id 1007 of card id 1014 of stack "untitled 1"

returns the text associated with that card, if the field exists on that
card, and an error if it doesn't, but if the stack is currently on a card
where the field doesn't exist, then (amazingly enough) this id

put the text of fld id 1007 of stack "untitled 1"

will return the text that last existed in that field on that card! In other
words, place the background with the field on card 1 of a stack. Put "This
is surprising" into the field. Remove the background from card 1. Then the
text of the field of the stack will be "This is surprising" even though the
field is no longer on card 1.

So for all purposes, is an ID like this sufficient?

<type> id <id> of stack "<stack name>"

with this for fields if accessing text:

field id <id> of card id <id> of stack "<stack name>"
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
That is what my ScriptTracker uses to build unique file names for the script of all controls (but I start with the stack).

If a card containing a certain shared group has not been visited, then the group must be referenced using background instead of group. For this reason, I use “bkgnd” to identify any shared group.

The background text issue is (was) actually a bug in the compact stack routine that should be fixed in 9.0.1 now. After you compact a stack (or save), then those extra contents should be gone. But you can still recover the text if you just remove it from a card and then place it before a compact is performed.

Thanks,
Brian
On Oct 11, 2018, 2:12 PM -0500, Geoff Canyon via use-livecode <[hidden email]>, wrote:

> I had never tried this before. It seems to work, but I figured I'd run it
> by the list, both as a way of confirming and informing.
>
> Is it accurate that
>
> <type> id <id> of stack "<stack name>"
>
> is a complete and unique identifier for any control? (with the exception
> for fields noted below)
>
> For example, suppose there is a button in a group in a group that is a
> background in stack "untitled 1". Further, suppose that background is not
> placed on the current (or any) card in stack "untitled 1". Then the long id
> of the button might be:
>
> button id 1003 of group id 1004 of bkgnd id 1006 of stack "Untitled 1"
>
> But, for example, this returns true:
>
> put there is a button id 1003 of stack "untitled 1"
>
> And as far as I know, there will never be any other button with id 1003 in
> that stack. So
>
> button id 1003 of stack "untitled 1"
>
> is a unique and permanent id for that button, no matter what card, group,
> or background it is in/on or not.
>
> Is this correct? (mind blown if it is)
>
> And of course I recognize that in the unique(?) case of a field with
> sharedText set to false, the rest of the id could matter as far as the
> htmlText, text, and rtfText are concerned. I just tested, and it seems that
> in that case the groups are still irrelevant, and an ID like
>
> put the text of fld id 1007 of card id 1014 of stack "untitled 1"
>
> returns the text associated with that card, if the field exists on that
> card, and an error if it doesn't, but if the stack is currently on a card
> where the field doesn't exist, then (amazingly enough) this id
>
> put the text of fld id 1007 of stack "untitled 1"
>
> will return the text that last existed in that field on that card! In other
> words, place the background with the field on card 1 of a stack. Put "This
> is surprising" into the field. Remove the background from card 1. Then the
> text of the field of the stack will be "This is surprising" even though the
> field is no longer on card 1.
>
> So for all purposes, is an ID like this sufficient?
>
> <type> id <id> of stack "<stack name>"
>
> with this for fields if accessing text:
>
> field id <id> of card id <id> of stack "<stack name>"
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
This is true, until you copy the control and paste it elsewhere, or copy/clone a group or card it belongs to and paste it elsewhere. The stack has an auto incrementing ID, and any time a new object is created it gets that ID, and the stack ID is incremented by 1. This is a blessing and a curse. You have to think if it as the ID of the INSTANCE of an object. For instance (no pun intended) every time a datagrid redraws, it creates all new objects, and each object gets the next ID. I think my project has IDs in the millions now.

I'm not sure if there is a limit for these IDs. When datagrids first came out, this was a discussion that was had, about what would happen if a stack eventually reached this limit. However, I think the limit is so incredibly high that it is extremely unlikely.

Bob S


> On Oct 11, 2018, at 12:11 , Geoff Canyon via use-livecode <[hidden email]> wrote:
>
> I had never tried this before. It seems to work, but I figured I'd run it
> by the list, both as a way of confirming and informing.
>
> Is it accurate that
>
> <type> id <id> of stack "<stack name>"
>
> is a complete and unique identifier for any control? (with the exception
> for fields noted below)
>
> For example, suppose there is a button in a group in a group that is a
> background in stack "untitled 1". Further, suppose that background is not
> placed on the current (or any) card in stack "untitled 1". Then the long id
> of the button might be:
>
> button id 1003 of group id 1004 of bkgnd id 1006 of stack "Untitled 1"
>
> But, for example, this returns true:
>
> put there is a button id 1003 of stack "untitled 1"
>
> And as far as I know, there will never be any other button with id 1003 in
> that stack. So
>
> button id 1003 of stack "untitled 1"
>
> is a unique and permanent id for that button, no matter what card, group,
> or background it is in/on or not.
>
> Is this correct? (mind blown if it is)


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
> Bob S. wrote:
> I think my project has IDs in the millions now.

OMG!

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
On Thu, Oct 11, 2018 at 12:38 PM Brian Milby via use-livecode <
[hidden email]> wrote:

> That is what my ScriptTracker uses to build unique file names for the
> script of all controls (but I start with the stack).
>
> If a card containing a certain shared group has not been visited, then the
> group must be referenced using background instead of group. For this
> reason, I use “bkgnd” to identify any shared group.


Not sure what you mean by this? I created a stack with a background/group
id 1011. The group is placed on card 4 of the stack. Restart LC and re-open
the stack, and this puts true:

put there is a group id 1011 of stack "untitled 1"

No card containing the group had been visited. This is on a Mac, LC 8.x

gc
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
On 10/11/2018 12:11 PM, Geoff Canyon via use-livecode wrote:

> And as far as I know, there will never be any other button with id 1003 in
> that stack. So
>
> button id 1003 of stack "untitled 1"
>
> is a unique and permanent id for that button, no matter what card, group,
> or background it is in/on or not.
>
> Is this correct? (mind blown if it is)

Not quite. Aside from cloning objects and the datagrid weirdness, as
already mentioned, ids have been mutable for several years now. The only
restrictions are that you can't have duplicate object ids in the same
stack and that you can't decrease the id of a stack (it can only be
increased).

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
Mutable, as in the engine or IDE change it without user interaction???

Bob S


> On Oct 11, 2018, at 14:15 , Mark Wieder via use-livecode <[hidden email]> wrote:
>
> Not quite. Aside from cloning objects and the datagrid weirdness, as already mentioned, ids have been mutable for several years now.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
I guess I should have said, "as unique as the standard 'long id' form of
identification" meaning that there is no circumstance where the long id
will resolve correctly, but <type> id <id> of stack "<stack name>" will
fail, or field id <id> of card id <id> of stack "<stack name>" will fail.

I understand that there is no such thing as a permanent id in LC.

On Thu, Oct 11, 2018 at 2:15 PM Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 10/11/2018 12:11 PM, Geoff Canyon via use-livecode wrote:
>
> > And as far as I know, there will never be any other button with id 1003
> in
> > that stack. So
> >
> > button id 1003 of stack "untitled 1"
> >
> > is a unique and permanent id for that button, no matter what card, group,
> > or background it is in/on or not.
> >
> > Is this correct? (mind blown if it is)
>
> Not quite. Aside from cloning objects and the datagrid weirdness, as
> already mentioned, ids have been mutable for several years now. The only
> restrictions are that you can't have duplicate object ids in the same
> stack and that you can't decrease the id of a stack (it can only be
> increased).
>
> --
>   Mark Wieder
>   [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
On 10/11/2018 02:19 PM, Bob Sneidar via use-livecode wrote:
> Mutable, as in the engine or IDE change it without user interaction???

No, you have to work at it explicitly. I'm sorry to say that I pushed
for this some years ago in a misguided assumption that this would help
advance the cause of version control. That allowed me to reconstruct
objects from script, then Monte came up with a different and better
solution, and then they both got rejected. So now you can assign and
change object ids and it still won't do you any good.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
>
> > If a card containing a certain shared group has not been visited, then
> the
> > group must be referenced using background instead of group. For this
> > reason, I use “bkgnd” to identify any shared group.
>
> Not sure what you mean by this? I created a stack with a background/group
> id 1011. The group is placed on card 4 of the stack. Restart LC and re-open
> the stack, and this puts true:
>
> put there is a group id 1011 of stack "untitled 1"
>
> No card containing the group had been visited. This is on a Mac, LC 8.x
>
> gc
>
>
I did not phrase that well (and had the details wrong).  What actually
happens is that the returned long ID of objects in shared groups changes
depending on whether a card containing that group has been visited.  If a
card has been visited, then "group id x of card id y" is returned.  If not,
then "bkgnd id x" is returned.  Probably not an issue for most, but if
looking to generate long IDs that are always the same for a given object
then it is.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
Ah, okay -- I have somewhat the same issue in Navigator. Wouldn't

group id <id> of stack "<stack name>"

always work?

On Thu, Oct 11, 2018 at 2:40 PM Brian Milby via use-livecode <
[hidden email]> wrote:

> >
> > > If a card containing a certain shared group has not been visited, then
> > the
> > > group must be referenced using background instead of group. For this
> > > reason, I use “bkgnd” to identify any shared group.
> >
> > Not sure what you mean by this? I created a stack with a background/group
> > id 1011. The group is placed on card 4 of the stack. Restart LC and
> re-open
> > the stack, and this puts true:
> >
> > put there is a group id 1011 of stack "untitled 1"
> >
> > No card containing the group had been visited. This is on a Mac, LC 8.x
> >
> > gc
> >
> >
> I did not phrase that well (and had the details wrong).  What actually
> happens is that the returned long ID of objects in shared groups changes
> depending on whether a card containing that group has been visited.  If a
> card has been visited, then "group id x of card id y" is returned.  If not,
> then "bkgnd id x" is returned.  Probably not an issue for most, but if
> looking to generate long IDs that are always the same for a given object
> then it is.
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
On Thu, Oct 11, 2018 at 2:36 PM Mark Wieder via use-livecode <
[hidden email]> wrote:

> On 10/11/2018 02:19 PM, Bob Sneidar via use-livecode wrote:
> > Mutable, as in the engine or IDE change it without user interaction???
>
> No, you have to work at it explicitly. I'm sorry to say that I pushed
> for this some years ago in a misguided assumption that this would help
> advance the cause of version control. That allowed me to reconstruct
> objects from script, then Monte came up with a different and better
> solution, and then they both got rejected. So now you can assign and
> change object ids and it still won't do you any good.
>

There have been multiple export/import functions written (I wrote one of
the first, about 15(?) years ago). Granted that it's not the integrated
solution you would hope for, how does it fall short of allowing version
control of project configuration?
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
That works to touch the object, but I am recording a long ID and long name in the exported script comment header. For background groups I didn’t want the card in there since the group could be on multiple. If I left it in, then the reported long ID would change depending on the last card containing the group that was visited. So I adjust the value to be consistent. I also swap out the stack path and use the name.

Thanks,
Brian
On Oct 11, 2018, 4:49 PM -0500, Geoff Canyon via use-livecode <[hidden email]>, wrote:

> Ah, okay -- I have somewhat the same issue in Navigator. Wouldn't
>
> group id <id> of stack "<stack name>"
>
> always work?
>
> On Thu, Oct 11, 2018 at 2:40 PM Brian Milby via use-livecode <
> [hidden email]> wrote:
>
> > >
> > > > If a card containing a certain shared group has not been visited, then
> > > the
> > > > group must be referenced using background instead of group. For this
> > > > reason, I use “bkgnd” to identify any shared group.
> > >
> > > Not sure what you mean by this? I created a stack with a background/group
> > > id 1011. The group is placed on card 4 of the stack. Restart LC and
> > re-open
> > > the stack, and this puts true:
> > >
> > > put there is a group id 1011 of stack "untitled 1"
> > >
> > > No card containing the group had been visited. This is on a Mac, LC 8.x
> > >
> > > gc
> > >
> > >
> > I did not phrase that well (and had the details wrong). What actually
> > happens is that the returned long ID of objects in shared groups changes
> > depending on whether a card containing that group has been visited. If a
> > card has been visited, then "group id x of card id y" is returned. If not,
> > then "bkgnd id x" is returned. Probably not an issue for most, but if
> > looking to generate long IDs that are always the same for a given object
> > then it is.
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
I see where you are going here. So placing a group on a card has the effect of actually copying the group to the new card? That is the only way I can see it having new IDs if visited. I was under the impression that placing a group on another card simply made it visible, but I can see that would only work if backgroundBehavior was set to true. Faced with this twist, I don't think I would ever attempt to catalog and store every object on a card or in a stack. Too convoluted. (Or should I say Revoluted...?)

Bob S


> On Oct 11, 2018, at 14:58 , Brian Milby via use-livecode <[hidden email]> wrote:
>
> That works to touch the object, but I am recording a long ID and long name in the exported script comment header. For background groups I didn’t want the card in there since the group could be on multiple. If I left it in, then the reported long ID would change depending on the last card containing the group that was visited. So I adjust the value to be consistent. I also swap out the stack path and use the name.
>
> Thanks,
> Brian

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
On 10/11/2018 02:52 PM, Geoff Canyon via use-livecode wrote:

> On Thu, Oct 11, 2018 at 2:36 PM Mark Wieder via use-livecode <
> [hidden email]> wrote:
>
>> On 10/11/2018 02:19 PM, Bob Sneidar via use-livecode wrote:
>>> Mutable, as in the engine or IDE change it without user interaction???
>>
>> No, you have to work at it explicitly. I'm sorry to say that I pushed
>> for this some years ago in a misguided assumption that this would help
>> advance the cause of version control. That allowed me to reconstruct
>> objects from script, then Monte came up with a different and better
>> solution, and then they both got rejected. So now you can assign and
>> change object ids and it still won't do you any good.
>>
>
> There have been multiple export/import functions written (I wrote one of
> the first, about 15(?) years ago). Granted that it's not the integrated
> solution you would hope for, how does it fall short of allowing version
> control of project configuration?

Well, git integration is a big part of what I want. That allows for true
group collaboration: checkouts, pull requests, merges, etc. Script-only
stacks is a step in that direction, missing I think only the use of
metadata for custom properties and the ability to use SSO stacks as
substacks. If it weren't for the stupid requirement for trailing
whitespace at the end of every line I'd actually go back to submitting
pull requests on SSO stacks.

If this were an actual project, I'd expect maybe a project config file
showing the stack(s), stack files, and other assets: font files, image
files, audio files, etc.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
The actual ID number does not change, but rather the full long ID. If no card has been visited containing the group then it is [bkgnd id 100x of stack “.../test”].
If it has, then it is based on the last card visited [group id 100x of card id 100y of stack “.../test”].

Thanks,
Brian
On Oct 11, 2018, 5:36 PM -0500, Bob Sneidar via use-livecode <[hidden email]>, wrote:

> I see where you are going here. So placing a group on a card has the effect of actually copying the group to the new card? That is the only way I can see it having new IDs if visited. I was under the impression that placing a group on another card simply made it visible, but I can see that would only work if backgroundBehavior was set to true. Faced with this twist, I don't think I would ever attempt to catalog and store every object on a card or in a stack. Too convoluted. (Or should I say Revoluted...?)
>
> Bob S
>
>
> > On Oct 11, 2018, at 14:58 , Brian Milby via use-livecode <[hidden email]> wrote:
> >
> > That works to touch the object, but I am recording a long ID and long name in the exported script comment header. For background groups I didn’t want the card in there since the group could be on multiple. If I left it in, then the reported long ID would change depending on the last card containing the group that was visited. So I adjust the value to be consistent. I also swap out the stack path and use the name.
> >
> > Thanks,
> > Brian
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
It actually isn’t that bad. You just need to handle shared groups separately and not for each card where they appear.

Thanks,
Brian
On Oct 11, 2018, 5:36 PM -0500, Bob Sneidar via use-livecode <[hidden email]>, wrote:

> I see where you are going here. So placing a group on a card has the effect of actually copying the group to the new card? That is the only way I can see it having new IDs if visited. I was under the impression that placing a group on another card simply made it visible, but I can see that would only work if backgroundBehavior was set to true. Faced with this twist, I don't think I would ever attempt to catalog and store every object on a card or in a stack. Too convoluted. (Or should I say Revoluted...?)
>
> Bob S
>
>
> > On Oct 11, 2018, at 14:58 , Brian Milby via use-livecode <[hidden email]> wrote:
> >
> > That works to touch the object, but I am recording a long ID and long name in the exported script comment header. For background groups I didn’t want the card in there since the group could be on multiple. If I left it in, then the reported long ID would change depending on the last card containing the group that was visited. So I adjust the value to be consistent. I also swap out the stack path and use the name.
> >
> > Thanks,
> > Brian
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Confirming a thing about IDs

Geoff Canyon via use-livecode
In reply to this post by Geoff Canyon via use-livecode
Yep, I feel you on the groups vs. cards aspect -- there are numerous
functions in Navigator that deal with "all objects in a stack" and I think
my code for de-duping (or avoiding duping, more accurately) is about to get
simpler...

On Thu, Oct 11, 2018 at 3:03 PM Brian Milby via use-livecode <
[hidden email]> wrote:

> That works to touch the object, but I am recording a long ID and long name
> in the exported script comment header. For background groups I didn’t want
> the card in there since the group could be on multiple. If I left it in,
> then the reported long ID would change depending on the last card
> containing the group that was visited. So I adjust the value to be
> consistent. I also swap out the stack path and use the name.
>
> Thanks,
> Brian
> On Oct 11, 2018, 4:49 PM -0500, Geoff Canyon via use-livecode <
> [hidden email]>, wrote:
> > Ah, okay -- I have somewhat the same issue in Navigator. Wouldn't
> >
> > group id <id> of stack "<stack name>"
> >
> > always work?
> >
> > On Thu, Oct 11, 2018 at 2:40 PM Brian Milby via use-livecode <
> > [hidden email]> wrote:
> >
> > > >
> > > > > If a card containing a certain shared group has not been visited,
> then
> > > > the
> > > > > group must be referenced using background instead of group. For
> this
> > > > > reason, I use “bkgnd” to identify any shared group.
> > > >
> > > > Not sure what you mean by this? I created a stack with a
> background/group
> > > > id 1011. The group is placed on card 4 of the stack. Restart LC and
> > > re-open
> > > > the stack, and this puts true:
> > > >
> > > > put there is a group id 1011 of stack "untitled 1"
> > > >
> > > > No card containing the group had been visited. This is on a Mac, LC
> 8.x
> > > >
> > > > gc
> > > >
> > > >
> > > I did not phrase that well (and had the details wrong). What actually
> > > happens is that the returned long ID of objects in shared groups
> changes
> > > depending on whether a card containing that group has been visited. If
> a
> > > card has been visited, then "group id x of card id y" is returned. If
> not,
> > > then "bkgnd id x" is returned. Probably not an issue for most, but if
> > > looking to generate long IDs that are always the same for a given
> object
> > > then it is.
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode