Images are being displayed for no reason??!!??

[Andrew Falanga]

Hi everyone,

I've been working on some code that compares graphic images, *not*
displays them. What's odd is that, sometimes, when running the
program the images that are being compared are suddenly opened and
displayed in the, "Windows Picture and Fax Viewer," program. I'm not
doing anything that would cause this.

I've narrowed it down to its happening in a place where I call into an
unmanaged dll that, at some point, uses GraphicsMagick to convert the
image to the PNM file format. I haven't been able to determine
exactly where though. The second thing I've noticed is that it
happens only when I'm debugging. Further, I found that this only
happens when I have the check marked to, "Enable Visual Studio Hosting
Process." If I debug with this turned off, the images aren't opened
for me in the, "Windows Picture and Fax Viewer," program.

Has anyone any ideas why this would be happening?

Thanks,
Andy

 

[Jeroen Mostert]

I've been working on some code that compares graphic images, *not*
displays them. What's odd is that, sometimes, when running the
program the images that are being compared are suddenly opened and
displayed in the, "Windows Picture and Fax Viewer," program. I'm not
doing anything that would cause this.

I've narrowed it down to its happening in a place where I call into an
unmanaged dll that, at some point, uses GraphicsMagick to convert the
image to the PNM file format. I haven't been able to determine
exactly where though. The second thing I've noticed is that it
happens only when I'm debugging. Further, I found that this only
happens when I have the check marked to, "Enable Visual Studio Hosting
Process." If I debug with this turned off, the images aren't opened
for me in the, "Windows Picture and Fax Viewer," program.

Has anyone any ideas why this would be happening?

Sure. Rather than invoking the external program, the image file is invoked
instead, causing the shell to open it.

Why, exactly, does that happen? Who cares? The problem is solved when you
disable the hosting process, which is generally one of the most useless
things ever. It's supposed to speed up debugging, something I have never
witnessed, and it demonstrably changes the behavior of the program in subtle
ways (like this one, apparently, I've seen others). An unlikely interaction
for sure, but not inconceivable. Since no release version of the program
will ever run under the hosting process, just don't use it.

If you're feeling adventurous, hook up an unmanaged debugger to the hosting
process (like windbg), set a breakpoint on, I'm guessing ShellExecute() and
CreateProcess(), and see what's happening. Unless you're interested in
*fixing* whatever bug/interaction in the hosting process and the unmanaged
DLL is causing the problem, though (without source, I suppose) there's no point.

 

[Andrew Falanga]

Sure. Rather than invoking the external program, the image file is invoked
instead, causing the shell to open it.

Why, exactly, does that happen? Who cares? The problem is solved when you
disable the hosting process, which is generally one of the most useless
things ever. It's supposed to speed up debugging, something I have never
witnessed, and it demonstrably changes the behavior of the program in subtle
ways (like this one, apparently, I've seen others). An unlikely interaction
for sure, but not inconceivable. Since no release version of the program
will ever run under the hosting process, just don't use it.

If you're feeling adventurous, hook up an unmanaged debugger to the hosting
process (like windbg), set a breakpoint on, I'm guessing ShellExecute() and
CreateProcess(), and see what's happening. Unless you're interested in
*fixing* whatever bug/interaction in the hosting process and the unmanaged
DLL is causing the problem, though (without source, I suppose) there's no point.

Do you know if the unit test framework, mstest (I hope I'm using the
right terms here), uses this hosting process? My library is being
used by others using mstest and this happens to them, occasionally
only. As I mentioned, it only happens to me when I'm debugging *and*
the debugger is set to use the hosting process.

Andy

 

[Jeroen Mostert]

Do you know if the unit test framework, mstest (I hope I'm using the
right terms here), uses this hosting process?

No. I would be highly surprised if it does, though. I should think the unit
tester is invoked externally and bypasses the VS mechanisms altogether.

My library is being used by others using mstest and this happens to them,
occasionally only. As I mentioned, it only happens to me when I'm
debugging *and* the debugger is set to use the hosting process.

A real possibility is that the unmanaged library just contains a plain old
ordinary bug, that running under the hosting process manages to unearth
because it simply changes things like the memory layout. Ditto for running
it under the unit tester.

One option is to use something more reliable. I would be wary of a library
that does nothing more useful than delegate to an external process to do the
actual work, seems like a slow and roundabout way of doing things (and
useless in an environment where you can't generate temporary files). Easy to
program, yes, but even that doesn't seem to be a guarantee for flawless
operation...

ImageMagick has a library interface and apparently .NET bindings for it as
well, I'd look into that. If that's no good, consider not using the
unmanaged library and invoking ImageMagick yourself directly from managed
code. This is not hard and unmanaged code doesn't make it any easier.

 

[Andrew Falanga]

This is believable.


This is not. Image files don't just spontaneously open themselves. You
must be doing _something_, either directly or indirectly, that results in
it happening.

As long as you believe nothing about your own actions or code has anything
to do with the problem, you aren't going to find a solution.

Then let me be a bit more precise, I didn't write the unmanaged code
into which I call that seems to be doing this. This is why I say,
"I'm not doing it."


I'm writing a class library. I have a test driver program for the
class library that is a command line program. The unmanaged dll uses
the CImg library (cimg.sourceforge.net) for various image processing
capabilities. At some point, the CImg library converts the input file
types to PNM files (unless the input is a PNM). It does so because I
do not have libraries such as libjpeg, or libtiff installed. The CImg
library uses the Graphics Magick program for the image file
conversion. It does so by building this command string:

<path_to_gm.exe> convert <source_image> <destination.pnm>

Frankly, *nothing* in the command string looks like it would cause
this. Further, it doesn't do this all the time. It seems to only
happen when using that hosting process in Visual Studio.

Andy

 

[Andrew Falanga]

No. I would be highly surprised if it does, though. I should think the unit
tester is invoked externally and bypasses the VS mechanisms altogether.


A real possibility is that the unmanaged library just contains a plain old
ordinary bug, that running under the hosting process manages to unearth
because it simply changes things like the memory layout. Ditto for running
it under the unit tester.

This could be the case. The version of the library I'm using is
somewhat "old" as there are newer releases. I tried porting the code
I'm using to the newest release but, apparently, enough changed in
CImg that the newest version broke functionality that the library I'm
using was dependent upon. Didn't have much of a choice but to revert
to the version I started with (of CImg that is).

One option is to use something more reliable. I would be wary of a library
that does nothing more useful than delegate to an external process to do the
actual work, seems like a slow and roundabout way of doing things (and
useless in an environment where you can't generate temporary files). Easyto
program, yes, but even that doesn't seem to be a guarantee for flawless
operation...

The CImg library is more than a simple pass through and is used quite
extensively in the library I'm using. CImg is a single C++ header
file, designed thusly by the author for maximum portability (take it
up with him if you think otherwise ). Although I'm not a graphics
expert, from what I've seen, this library makes working with graphic
files quite easy and is meant for much, much more than to simply open
and display them. The library allows for easy access to pixel data
and many more features which I honestly know nothing about. Suffice
it to say, it's much more than a simple means of converting the file
from one form to another.

ImageMagick has a library interface and apparently .NET bindings for it as
well, I'd look into that. If that's no good, consider not using the
unmanaged library and invoking ImageMagick yourself directly from managed
code. This is not hard and unmanaged code doesn't make it any easier.

Incidentally, GraphicsMagick is an improvement upon Image Magick
(their words not mine). From what I saw at the Graphics Magick web
site, it looks like Graphics Magick was "born" out of Image Magick.

The idea, though, of converting the image myself, using Graphics
Magick, to a PNM file and then calling my unmanaged library is a very
good suggestion given the circumstances.

Andy