jhurley at infostations.com
Tue Feb 4 13:14:01 CST 2003
> mark mitchell 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
>> 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
(especially relative to HC's resource fork and pict external).
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.
More information about the use-livecode