[Mono-list] Backdrop behaving different in Mono

[Jonathan Gilbert]

At 02:03 PM 17/05/2006 -0600, Glen Farrell wrote: 
> Hi, I've created an MDI window with a toolbar on the right side. I'm
> trying to load a backdrop image from a file, and display it as the
> background for the MDI window. So I've added this code to the form
> constructor:
> 
> System.Drawing.Image Backdrop = System.Drawing.Image.FromFile("Images"
> + System.IO.Path.DirectorySeparatorChar + "Backdrop.jpg");
> this.BackgroundImage = Backdrop;

Though it is not the cause of the problem, this is not an appropriate way
to build a path. You should use the Path.Combine method:

S.D.Image Backdrop = S.D.Image.FromFile(System.IO.Path.Combine("Images",
"Backdrop.jpg"));

Though it is bad form, you could actually simply hardcode a "/" as well;
Windows does actually support it in all the underlying APIs, even though
the front-end user interface usually insists on "\"s.

If this image isn't going to change, ever, though, then the best course of
action would be to embed it as a resource; that way, there's no chance of
it going missing, and you don't need to worry about path separator
characters at all :-)

S.D.Image Backdrop = S.D.Image.FromStream(
  GetType().Assembly.GetManifestResourceStream("Backdrop.jpg"));

Note that if you embed it using Visual Studio, then the name will be
prefixed with the name of your assembly. If your project is called
"MDIWithBackdrop", then you'd actually need to pass
"MDIWithBackdrop.Backdrop.jpg" to Assembly.GetManifestStream().

In order to embed it with Visual Studio, add it to the project, and then in
the Solution Explorer, right click on the file and select "Properties".
Then, in the properties panel, change the Build Action from "None" to
"Embedded Resource".

> Now this code works fine running it directly from Visual Studio (in
> Windows). However (using the VSPrj2Make add-in), when I test it with
> Mono (1.1.15), the backdrop image appears on the toolbar instead!
> 
> Do I need to do this differently in Mono?

This is almost certainly a bug in Managed.Windows.Forms; your program
should magically begin to work (without even recompiling) when it is fixed.
Probably someone closer to the core of M.W.F development will respond to
confirm this.

Jonathan Gilbert