Judy Perry <[EMAIL PROTECTED]> 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.Maybe it's the non-assembly code programmer in me, but it's just not clear why, once you've embedded something, you have to re-embed it with each usage. This is just nuts. This results in bloatware.
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.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
