Help: Id's can be completly unreliable
bobs at twft.com
Wed Nov 10 18:00:45 CST 2010
It's my understanding that object ID's inside a stack are maintained by the engine to ensure uniqueness. I would not mess with the ID's at all. I remember back in Hypercard that was a big no-no as well.
About the only use of ID's that I can see would be if you were programmatically renaming objects, and you wanted to reference the same object after the rename with something that didn't change. I know that Trevor uses the long id of a button to define the storage object for sqlYoga, because someone might rename the button and break their own code. But changing ID's is IMHO a bad practice.
On Nov 10, 2010, at 3:54 PM, Monte Goulding wrote:
>> Thanks for the background on that.
>> If you have a recipe for that please submit a bug report, but to be honest I've never seen anything like that in 12 years of working with this engine.
>> IDs normally begin at 1001 and increment from there for every object added to the stack.
> I tried setting the stack id to 0 which should mean the id of the next control to be added to the stack would be 0 and it causes an execution error. Interestingly though it is possible to set the id to a negative number although ids of new objects will always be greater than 0. I ended up with two buttons with the same id which means you can't inspect the second one.
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode