Re: Confirming a thing about IDs
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 < use-livecode@lists.runrev.com> 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 < > use-livecode@lists.runrev.com>, wrote: > > Ah, okay -- I have somewhat the same issue in Navigator. Wouldn't > > > > group id of stack "" > > > > always work? > > > > On Thu, Oct 11, 2018 at 2:40 PM Brian Milby via use-livecode < > > use-livecode@lists.runrev.com> 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 > > > 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 > ___ > 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: Confirming a thing about IDs
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 , 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 > > 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 > 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: Confirming a thing about IDs
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 , 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 > > 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 > 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: Confirming a thing about IDs
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 < use-livecode@lists.runrev.com> 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 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: Confirming a thing about IDs
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 > 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 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: Confirming a thing about IDs
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 , wrote: > Ah, okay -- I have somewhat the same issue in Navigator. Wouldn't > > group id of stack "" > > always work? > > On Thu, Oct 11, 2018 at 2:40 PM Brian Milby via use-livecode < > use-livecode@lists.runrev.com> 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 > > 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 ___ 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: Confirming a thing about IDs
On Thu, Oct 11, 2018 at 2:36 PM Mark Wieder via use-livecode < use-livecode@lists.runrev.com> 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 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: Confirming a thing about IDs
Ah, okay -- I have somewhat the same issue in Navigator. Wouldn't group id of stack "" always work? On Thu, Oct 11, 2018 at 2:40 PM Brian Milby via use-livecode < use-livecode@lists.runrev.com> 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 > 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: Confirming a thing about IDs
> > > 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 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: Confirming a thing about IDs
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 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: Confirming a thing about IDs
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 id of stack "" will fail, or field id of card id of stack "" 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 < use-livecode@lists.runrev.com> 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 > 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 > ___ 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: Confirming a thing about IDs
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 > 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 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: Confirming a thing about IDs
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 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: Confirming a thing about IDs
On Thu, Oct 11, 2018 at 12:38 PM Brian Milby via use-livecode < use-livecode@lists.runrev.com> 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 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: Confirming a thing about IDs
> Bob S. wrote: > I think my project has IDs in the millions now. OMG! ___ 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: Confirming a thing about IDs
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 > 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 > > id of stack "" > > 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 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: Confirming a thing about IDs
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 , 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 > > id of stack "" > > 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? > > id of stack "" > > with this for fields if accessing text: > > field id of card id of stack "" > ___ > 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
Confirming a thing about IDs
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 id of stack "" 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? id of stack "" with this for fields if accessing text: field id of card id of stack "" ___ 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
