While you may be correct that p.PictureData is not legitimate in the try and
is legitimate in the catch, I don't see how that can happen. The
BackgroundWorker does not use the the instance of the object for p after
calling ReportProgress. I can't find any other alternate thread references
to the stream that would exist to indicate that a missing value would have
been updated in p in between.
In the BackgroundWorker code, ReportProgress would never be called if the
stream was not initialized.
Here is the code that initializes the stream:
First, I make sure the source image file exists:
if (File.Exists(picturePath))
{
imageStream = GetImageStream(picturePath);
}
Then I fill imageStream with the image by assigning the return value from
this code:
FileStream fs = File.Open(path, FileMode.Open, FileAccess.Read,
FileShare.Read);
MemoryStream ms = new MemoryStream((int)fs.Length);
const int size = 4096;
byte[] bytes = new byte[4096];
int numBytes;
while ((numBytes = fs.Read(bytes, 0, size)) > 0)
ms.Write(bytes, 0, numBytes);
fs.Close();
fs.Dispose();
return ms;
Then I make sure that imageStream is not null and that it has something in
it with this code I just put in for troubleshooting. The if statement never
matches; the exception never gets thrown:
if (imageStream == null || imageStream.Length < 10000)
{
throw new Exception("Bad imageStream!!!");
}
And next comes a loop that uses the same stream several times including
calling ReportProgress where the exception occurs in the handler. In this
loop, some iterations will work and some will not. This pretty much proves
that the stream is valid since iteration 1 may work, 2 may not, maybe 3
through 6 will work, 7 will not, etc.
for (int count = 0; count < files.Length; count++)
{
ProcessImage(imageStream);
imagesProcessedCount++;
backgroundWorker1.ReportProgress(CalculatePercentComplete(fileCount,
imagesProcessedCount), new PictureProgress(
startingFolder,
imageFileName,
files[count],
fileCount,
imagesProcessedCount,
imageStream));
}
Because of the size and complexity of the application, recreating this bug
in code that could be posted here would be virtually impossible.
I guess I am hoping someone would have run across a similar roblem with GDI+
or System.Drawing in Vista X64, or with BackgroundWorker in Vista X64.
I don't know if it has any bearing or not, but if it is a race condition,
perhaps the fact that I have Vista X64 running on a dual quad-core Xeon
system and all the machines I run it on are single-core machines. I have had
quite a few people download the application from my site and while they have
had other feedback, this issue has never been reported by users either. I
doubt there has been any X64 installations; it isn't that widely spread.
Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA