Create Image, Hide Image

J. Landman Gay jacque at
Tue Dec 10 20:45:01 EST 2002

erik hansen <erikhans08 at> wrote:

> are there any problems with bringing in an image
> as an icon or saving an icon as an image? HC has
> a  useful 2-tone editor, MC i don't know about
> for editting icons and/or images.  all of my
> HC>MC icons have somehow become images in a
> RunRev group.
> maybe there is a workaround here.

When Rev does a HyperCard import, it looks in the HC stack's resource 
fork, grabs each icon as an image, and imports it into the new Rev 
stack. For convenience, it groups the HC images together. If you import 
an image from disk manually, it's essentially the same thing. So there 
is no disadvantage to importing images, and in fact, that's the usual 
way of getting custom icons into a stack.

An icon isn't any different from any other image in the stack. Often 
though, images used as icons are kept hidden, or placed in a substack, 
or put on an unused card so they don't get in the way. All that's needed 
to use them as icons is to assign the ID of their image object to the 
button's icon property. The images themselves don't have to be visible, 
and don't even have to be in the same stack as long as they are 
somewhere in the stack hierarchy.

Also, I just figured out what Rob was pointing out (getting the list in 
digest mode makes it hard to follow threads sometimes) -- so I should 
clarify my original statement that images have to "be in the stack". 
He's right that they don't. What I meant was, an image object containing 
the image content must be in the stack so that there is an ID number to 
use for the button icon. Whether the actual content of the image object 
is referenced from disk or stored in the stack isn't important.

I probably just muddled up that explanation even worse. ;)

Jacqueline Landman Gay         |     jacque at
HyperActive Software           |

More information about the Use-livecode mailing list