I've been trying to chase a very obscure bug that's something to do with setting the icon of a button to the ID of an image. During this (so far unsuccessful) activity, I've found some strange things - well, strange to me.
1. IDs are unique to a stack, but not unique to a whole stack file (the same ID can appear in different stacks), but the 'icon' property of an image is just a number - it can't be qualified by a stack name. In fact the TD says:
"You can set the ID of an image. Be careful not to set an image ID to a number that's the ID of another object in the same stack: since Revolution uses IDs to keep track of objects, a conflict may prevent Revolution from being able to access one or both objects."
But since you can't choose ID numbers (can you?) the possibility does exist of the icon property pointing to an unintended image (i.e. one in a different stack from the one intended). How can I make sure this doesn't happen? (BTW I think this is a rather sloppy exception to the normal scope rules, - you can imagine ID refs like 3.1055 meaning "ID 1055 in stack 3", which would be unique - but I guess there must be at least historical reasons for it).
2. If I set the icon property of a button using the IDE by clicking on the symbol next to the 'icon' field in the object's inspector, I then get a window which lists the available icons, including those in 'this stack' - but I now see that although all the images in the current stack are listed, some of then show **the wrong ID numbers** in the corresponding tooltip - the only way to find out which ID you're using. For example, one reported in its tooltip as ID 1043 turns out to have ID 1103 - 1043 was deleted from an earlier version and is not now assigned. Is this a bug?
3. I guess this is likely my fault, but it appears so far that if I set the icon of my button to an animated GIF (yes, that old thing!), for just some GIF IDs the animation doesn't show up, even though the GIF is merrily animating on its own card (not shown to the user). I'm not really asking for listers to waste any more time on this, but I admit I would be interested in any ideas about how I might attack the problem.
TIA
Graham
--
-------------------------------------------------------------------
Graham Samuel / The Living Fossil Co. / UK & France
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
