Nothing special.  It's just that if you use FromFile(), the Image hangs on  
to the file resource for you.  I believe that if you didn't close the  
stream, you'd find that SetActiveFrame() works as expected.

In other words, the issue here is that a TIFF-based Image requires the  
file to remain open in order to navigate the frames in the file.  It just  
happens that using FromFile(), that retention of the file resource happens  
automatically, while in the other case you're explicitly discarding the  
file resource.

I see a few options, in decreasing order of preference (for my taste,  
anyway):

    * Change the logic so that you don't close the stream/dispose the  
Image until you actually want to delete the file.  This of course would  
mean that once the file's deleted, the Image is no longer valid either (or  
at least cannot be switched to a different page of the TIFF, in the stream  
case)

    * Read the entire file into a MemoryStream and use that stream as the  
source for the Image instead.  This the most flexible, but given the  
potential for arbitrarily large TIFF files it could unnecessarily limit  
your ability to display any arbitrary TIFF file.

    * Copy the original file to a temp file, and use that file as the  
source for the Image instead.  This has the problem that for small files,  
you might as well just read them into memory, and for large files, copying  
the file may cause a prohibitive delay in presenting the image.  But at  
least it would work for arbitrarily large files, assuming enough disk  
space to copy the file.

Pete

According to reflector Image.FromStream() and Image.FromFile() are both
calling the same internal GDI methods.  Well, not the same but they ARE GDI
methods (I think)  It's hard to explain.  What I'm saying is that they both
look like they work the same way.

Sheesh!

So then I had this bright idea!
<code>
Image i = Bitmap.FromFile(filename);
Guard.ReferenceNotNull(i, "Failed loading Image from file: " + filename);

Image j = i.Clone() as Image;
i.Dispose();
return j;
</code>

It doesn't allow me to delete the file either "File locked by another
process...."
if I dispose j as well, then I can delete the file.  So it appears that
close still keep some reference to the source object?  That doesn't sound
right.

And finally:
<code>
Image i = Bitmap.FromFile(filename);
Guard.ReferenceNotNull(i, "Failed loading Image from file: " + filename);

//  try painting one into the other
Image freeCopy = new Bitmap(i);
i.Dispose();
return freeCopy;
</code>

This drops all the frames from the tiff.  I can delete the source file, but
th resultant Image is junk.

The only last option I have is to load the tiff, grab all the frames into an
Image[], dispose of the source tiff Image, delete the source file and just
work with the Image[] array.  This will work for my needs, but I imagine for
other it won't.

If anyone has any ideas or suggestion I would really like to hear them.

-Steve

This is what I'm using to read images w/o locking the file.

public static Image LoadImageFromFile(string fileName)
{
   Image theImage = null;
   using (FileStream fileStream = new FileStream(fileName, FileMode.Open,
FileAccess.Read))
   {
     byte[] img;
     img = new byte[fileStream.Length];
     fileStream.Read(img, 0, img.Length);
     fileStream.Close();
     theImage = Image.FromStream(new MemoryStream(img));
     img = null;
   }
   GC.Collect();
   return theImage;
}

Hope it works for you.

RobinS.
GoldMail, Inc.
------------------------

You stated in another post that your image data is coming directly from a
database blob field.  Why don't you just take this data and write it to a
MemoryStream and then do a FromStream method call to create the image?  This
way, you don't have to create/delete a file on the file system.

HTH,
Mythran