Icons, IDs and Image Library
xbury.cs at clearstream.com
xbury.cs at clearstream.com
Tue Dec 2 09:15:23 EST 2003
Shocking!
Sorry about the suggestion using the name! The name gets reverted to the
image
ID after a desel-reselection...
Be my guest to post another zilla bug...
On 02/12/2003 15:13:06 use-revolution-bounces wrote:
>First, the nice answer: The image's name can be used as the icon
>reference!
>
>Of course the one thing that could be also nice to use is the AltID prop
>but
>it's another missing piece in the Props palette. And you can't use it to
>assign
>a button an icon - so you wonder why it exists right?
>
>Now regarding confusion between two similar IDs in separate stacks, I'd
>avoid it!
>It seems that the first loaded ID is the one in use which may not be your
>choice...
>
>These would be nice feature requests but since my last 3 concize posts to
>bugzilla
>went lost, my 2 months-old bugzilla report is still untouched and Kevin
>still
>doesn't answer an important mail I sent him 2 months ago, I gave up using
>Confuzilla...
>
>Anyone else having problems with bugzilla?
>
>On 02/12/2003 14:44:40 use-revolution-bounces wrote:
>>I sent this email just now from the apple 'Mail' client and it
>>bounced. Possibly some of it got through - if so, apologies for the
>>partial double posting.
>>
>>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
>
>Visit us at http://www.clearstream.com
>
>IMPORTANT MESSAGE
>
>Internet communications are not secure and therefore Clearstream
International
>does not accept legal responsibility for the contents of this message.
>
>The information contained in this e-mail is confidential and may be
legally
>privileged. It is intended solely for the addressee. If you are not the
>intended recipient, any disclosure, copying, distribution or any action
taken
>or omitted to be taken in reliance on it, is prohibited and may be
unlawful.
>Any views expressed in this e-mail are those of the individual sender,
except
>where the sender specifically states them to be the views of Clearstream
>International or of any of its affiliates or subsidiaries.
>
>END OF DISCLAIMER
>_______________________________________________
>use-revolution mailing list
>use-revolution at lists.runrev.com
>http://lists.runrev.com/mailman/listinfo/use-revolution
Visit us at http://www.clearstream.com
IMPORTANT MESSAGE
Internet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.
The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.
END OF DISCLAIMER
More information about the use-livecode
mailing list