Re: Ugly ID memories
Bob Sneidar wrote: > On Dec 10, 2008, at 7:42 AM, Richard Gaskin wrote: > >> This is why the altID can be useful for restoring objects: >> the incrementer never works backward, so if you set the >> altID of a control to its actual ID prior to turning it into >> XML or some other representation, when you recreate it in >> the same stack you can be assured no other control is using >> that ID. > > Very useful tidbit there Richard! I did not know that! Yeah, the tough thing about Rev is that there's always something new to learn. But the great thing about Rev is that there's always something new to learn. :) -- Richard Gaskin Fourth World Revolution training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ugly ID memories
Very useful tidbit there Richard! I did not know that! Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Dec 10, 2008, at 7:42 AM, Richard Gaskin wrote: This is why the altID can be useful for restoring objects: the incrementer never works backward, so if you set the altID of a control to its actual ID prior to turning it into XML or some other representation, when you recreate it in the same stack you can be assured no other control is using that ID. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ugly ID memories
viktoras didziulis wrote: Richard Gaskin wrote: Any problems using the altID property? Since IDs increment for each object created, if restoring an object setting the altID should avoid any conflict with existing or new objects. Is there anything what can be done with ID that can't be done with altID? If not, then simply forgetting about existence of ID and using altID in all cases where we are used to refer to ID should solve the ID problem completely... For those who simply want an arbitrary integer they can control that would certainly do it. But what differentiates the altID from just using a custom property is that the altID is checked when addressing objects by ID. Strange but true, and very powerful, created to facilitate porting projects from other xTalks. When referrring to an object by ID, the built-in IDs are checked first, and if no match is found then the altIDs are checked. Objects are checked in layer order. So if you have a button whose ID is 1003, and an altID of , asking for either: btn id 1003 ...or: btn id ...will return the same control. As you can guess, this isn't entirely foolproof, because if you have a button with an actual ID of that one will be returned instead. But IDs for all objects use a single incrementer within a given stack, and the last ID used is stored in the stack's ID property (which otherwise has no useful purpose, since it changes whenever a new control is added, and stacks are required to have unique names anyway). This is why the altID can be useful for restoring objects: the incrementer never works backward, so if you set the altID of a control to its actual ID prior to turning it into XML or some other representation, when you recreate it in the same stack you can be assured no other control is using that ID. -- Richard Gaskin Fourth World Revolution training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ugly ID memories
Is there anything what can be done with ID that can't be done with altID ? If not, then simply forgetting about existence of ID and using altID in all cases where we are used to refer to ID should solve the ID problem completely... Viktoras Richard Gaskin wrote: Any problems using the altID property? Since IDs increment for each object created, if restoring an object setting the altID should avoid any conflict with existing or new objects. -- Richard Gaskin Fourth World Revolution training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ugly ID memories
Any problems using the altID property? Since IDs increment for each object created, if restoring an object setting the altID should avoid any conflict with existing or new objects. -- Richard Gaskin Fourth World Revolution training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ugly ID memories
In a message dated 12/9/08 6:06:08 PM, [EMAIL PROTECTED] writes: > Object ID's are simply a way for the software to uniquely identify an > object. That the ID is made visible to the programmer seems to me to > be a convenience. Since you can refer to an object by name anyway, > there really is no hard fast reason to refer to it by it's ID. It > would be like deleting a user profile in Windows, then creating > another and giving it the same ID. Hey, actually that would be cool! > But I digress. > > I have used that feature here and there; it is useful to have an object property that never changes regardless of name or number or whatever else that can. And do. It is a good thing, and I agreed, way back when, it should not be settable. It would have been just another number, then. ** Make your life easier with all your friends, email, and favorite sites in one place. Try it now. (http://www.aol.com/?optin=new-dp&icid=aolcom40vanity&; ncid=emlcntaolcom0010) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ugly ID memories
Object ID's are simply a way for the software to uniquely identify an object. That the ID is made visible to the programmer seems to me to be a convenience. Since you can refer to an object by name anyway, there really is no hard fast reason to refer to it by it's ID. It would be like deleting a user profile in Windows, then creating another and giving it the same ID. Hey, actually that would be cool! But I digress. Bob Sneidar IT Manager Logos Management Calvary Chapel CM On Dec 9, 2008, at 2:01 PM, [EMAIL PROTECTED] wrote: In a message dated 12/9/08 3:08:11 PM, [EMAIL PROTECTED] writes: To add to what Bjornke posted, if I delete a button and then want to recreate it (as in a version control storage and retrieval system), then there is *no way* to reuse its previous id in that stack. The id number is lost to history. The only workaround for this is too ugly to discuss in mixed company. There was a corollary debate in HC years back; whether the id should be a settable property. It was decided (very) on high that it would not be. The reasons are lost in time, but I recall it was felt that id's were not intended to be indexed, and that as permanent and unique as they were, id's also needed to die off completely if the object was deleted. A tribute, in fact, to their very uniqueness. In no way linkable, by design, to any remaining or future objects. And I would love to talk about a workaround. Perhaps remember the old id, linking it via a look-up table to some other object? But as before, nobody could think of a good reason to do so, that is, there was no value in knowing that a deleted id was either linked to or owned by any other object. Numbers were cheap back in those days, and the simple fact that every object had a unique one was considered more than sufficient. ** Make your life easier with all your friends, email, and favorite sites in one place. Try it now. (http://www.aol.com/?optin=new-dp&icid=aolcom40vanity&ncid=emlcntaolcom0010 ) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Ugly ID memories
In a message dated 12/9/08 3:08:11 PM, [EMAIL PROTECTED] writes: > To add to what Bjornke posted, if I delete a button and then want to > recreate it (as in a version control storage and retrieval system), > then there is *no way* to reuse its previous id in that stack. The id > number is lost to history. The only workaround for this is too ugly to > discuss in mixed company. > There was a corollary debate in HC years back; whether the id should be a settable property. It was decided (very) on high that it would not be. The reasons are lost in time, but I recall it was felt that id's were not intended to be indexed, and that as permanent and unique as they were, id's also needed to die off completely if the object was deleted. A tribute, in fact, to their very uniqueness. In no way linkable, by design, to any remaining or future objects. And I would love to talk about a workaround. Perhaps remember the old id, linking it via a look-up table to some other object? But as before, nobody could think of a good reason to do so, that is, there was no value in knowing that a deleted id was either linked to or owned by any other object. Numbers were cheap back in those days, and the simple fact that every object had a unique one was considered more than sufficient. ** Make your life easier with all your friends, email, and favorite sites in one place. Try it now. (http://www.aol.com/?optin=new-dp&icid=aolcom40vanity&ncid=emlcntaolcom0010) ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
