Storing images

[Jim Hurley]

>  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
(especially relative to HC's resource fork and pict external).

(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