Storing images

Chipp Walters chipp at chipp.com
Tue Feb 4 15:35:00 EST 2003


Judy,

Don't know about HC, but in RR when you delete the image....it's gone.

-Chipp

> -----Original Message-----
> From: use-revolution-admin at lists.runrev.com
> [mailto:use-revolution-admin at lists.runrev.com]On Behalf Of Judy Perry
> Sent: Tuesday, February 04, 2003 1:35 PM
> To: use-revolution at lists.runrev.com
> Subject: Re: Storing images
>
>
> 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.
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list