The id needs to include the stack reference, because it is a
reference to the target object.
Based on that, it doesn't matter that the path can change, since the
long id is only stored for the length of the call to the class group.
The class groups are referenced by name and the long id of the card
they are on. If the path to the HOOT stack changes while the library
is enabled, I suppose that could cause a problem, but that seems
unlikely.
gc
On Feb 27, 2006, at 10:09 AM, Mark Wieder wrote:
Geoff-
Looks nice. I'll spend some time with this today.
Regarding the "long id" thing, Dick Kriesel and I were talking about
this last month and I have now switched my usage over to just "the
id", based on the fact that ids within a stack are unique and
immutable. You can pass ids without any problem and it's just a single
data point: you don't have to parse it for path items at all.
control pID of this stack
does the trick. The only exception I had to implement is for messages
coming from or to a stack, since the stack id changes with each new
object. But I don't think you have to worry about this with your
subclassing. And note that it *is* possible to change the id of
images, although I haven't found a need for this myself and I'm not
sure if subclassing an image makes sense.
--
-Mark Wieder
[EMAIL PROTECTED]
_______________________________________________
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
