Storing images

[Judy Perry]

Perhaps my gripe stems (as usual) from a lack of understanding.  I've
tried something like this -- importing as a control some image.  But I
didn't want it on the card where I imported it (not thinking about where I
was; okay, it wasn't really me it was a student) and so I clicked on it
and hit the delete key.  On the same card, I tried "show image imageName"
and got nothing.  Now, if I recall correctly in HC, you can delete it on
the card (or funny color draw) layer but the image is still there in the
stack, waiting for you to show it again whenever you wish.

Am I wrong?  It's always sooo nice to be wrong about such things!

Judy

On Tue, 4 Feb 2003, J. Landman Gay wrote:

> I think there's some confusion -- you don't have to embed an image
> multiple times. Only one copy is needed. Actually, the Revolution way
> acts almost identically to HyperCard's resource-fork method, the only
> difference is that instead of placing the image in the Mac-only resource
> fork, you place it somewhere in the stack itself (or in any stack that
> is in the message hierarchy, such as a substack.) Once you get the image
> imported, it can be used over and over again without any duplication,
> just as addcolor does in HC.
>
> For example, in my Klondike game I have a card that the user never sees
> which stores all the images the stack needs. The game uses
> playing-card-sized buttons which constantly update their image to
> simulate whatever playing card is currently "face up". Scripts change
> the "playing card" button icon IDs as needed. It is a one-liner to place
> a RAM-based copy of the image if you use a button as the image container.
>
> In HyperCard, we would issue "addcolor colorBtn" along with a long
> string of parameters. This grabs a temporary copy of the image from the
> resource fork and places it over a button. In Revolution, we issue "set
> the icon of btn x to <myImgID>". This grabs a temporary copy of the
> image from the data fork and places it into a button as the icon. An
> extra advantage of this method is that, unlike addcolor images, you can
> move the button around without worrying about leaving the image display
> behind on screen.
>
> There is no duplication of the image graphic when you do this; Rev just
> inserts a temporary copy of the image into RAM just as addcolor does
> when it draws the image to screen. The only difference is the location
> of the original source image and, of course, the syntax used to set the
> button image.