(especially relative to HC's resource fork and pict external).mark mitchell wrote: Judy wrote:Yes, there are many different ways of doing one thing; problem is, it doesn't matter if they're all equally inelegant/non-intuitive. 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.I finally understand this thread. I couldn't figure out how "set the icon of button 1 to myImage" could possibly be described as inelegant
(snip)
Unfortunately, I know just enough about this issue to be dangerous.
Perhaps "inelegant" isn't the word, but it can be cumbersome to set the button icon to the image if you want to use different sizes on different card. You need a preOpenCard handler on each card on which the image appears in order to set the size of the image on that card. (If you lock the position and size you needn't worry about the location. That is held fixed. But you can reset the size through the script even though the imaged is lock.)
All of this is avoided if the image is referenced from a disk file. As I said before, the only problem this might pose is if the end user were careless or uninformed and separated the images from the folder to which they are linked in the stack.
A more elegant or less cumbersome solution (and idiot proof for the end user) would be to embed the single images in some "secret" place from which they might be referenced and a different size and location for the image could be locked on each card.
Thinking wishfully,
Jim
--
Jim Hurley
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
