Image Display Issues on Win XP

[Rob Cozens]

Bill,

>Yes, that is the basic idea... whatever is going to be the least demanding
>on system memory will work best. Use actual thumbnails when possible; load
>images into memory only when needed.

Thanks for the additional info.  One question: Does alwaysBuffer 
really mean anything if an image is added directly into a stack [as 
opposed to adding it by reference]?  It seems to me an image included 
in a stack file is always in memory once the stack is opened.

>Another method to consider is to keep the images out of the stack; encrypt
>the images on disk (encrypt command); and decrypt them (decrypt command) as
>they are loaded. This will make them slightly larger on disk and use more
>memory, but it will keep your stack small and stable.

Yes, it is a possibility.

>Keep in mind that without extreme workarounds (i.e., using certain DirectX
>routines), images are never really secure on a computer; a press of the
>Print Screen button will put that picture on the clipboard. By embedding
>them in a stack or encrypting the image files on disk, you're only making it
>a little less difficult to access them.

I understand.  It's a lot like anti-hacker protection: it's never 
going to be 100% effective, and there comes a point of diminishing 
returns where the additional protection is not worth the programming effort.

But here's a larger [& somewhat off topic] question:

Suppose one is creating a portfolio of photographic 
art.  Furthermore, assume the "original" photographs are sold as 
"one-of-a-kind" photos, with the proviso that the original electronic 
photo image is "destroyed" after a print is made.  How does one 
provide a likeness of the image (in 5 MPix detail) without providing 
access to the image file itself?

Rob Cozens, CCW
Serendipity Software Company

Vive R Revolution!