Last week, I created a WinForms signature capture panel and then rendered the data out to a webpage.  You can read about it here.  The problem is that I used Response.Write to write the image to the browser.  Even in a web control, the only thing shown in a browser is the image:


gives this:



I then decided that I should use a Web.UI.Image Control to render the image. 


The problem?  ImageUrl is the method you use to assign the image, and that only has 1 signature – 1 String that is the Url of the image that is, typically, located on the file system.



Without thinking too hard, I decided to put the image on the file system  and then point to the image in the code behind.

I wrote the following code:

private void LoadSignature()
    SignatureFactory signatureFactory = new SignatureFactory();
    String fileName = String.Format("~/images/Signature.bmp");

    using (Bitmap bitmap = new Bitmap(200, 100))
        using (Graphics graphics = Graphics.FromImage(bitmap))
            Signature signature = signatureFactory.LoadSignatureFromFileSystem(@"C:\Signatures\signature.xml");
            Pen pen = new Pen(Color.Black);

            SolidBrush solidBrush = new SolidBrush(Color.White);
            graphics.FillRectangle(solidBrush, 0, 0, 400, 50);

            foreach (Glyph glyph in signature.Glyphs)
                foreach (Line line in glyph.Lines)
                    graphics.DrawLine(pen, line.StartPoint.X, line.StartPoint.Y,
                        line.EndPoint.X, line.EndPoint.Y);
            bitmap.Save(fileName, System.Drawing.Imaging.ImageFormat.Bmp);
    this.signatureImage.ImageUrl = fileName;

When I ran it, I got the following exception:


Carp!  And no inner exception to boot!  When you Bing/Google/AskJeeves this exception, you get TONS of potential reasons (Security, Location, OOM, etc…) – basically, the managed wrapper for the CGI+ call didn’t implement any exceptions.  Without knowing anything about the implementation, I have to believe that HRESULT did return something, MSFT was just to lazy busy to send out meaningful exception message.

After screwing around for a bit, I would get the message to write to the file system by hard-coding the path like so:

//String fileName = String.Format("~/images/Signature.bmp");
String fileName = String.Format(@"C:\Users\Jamie\Desktop\Tff.SignatureCapture\Tff.SignatureCapture.WebForm\images\Signature.bmp");

The problem is that the Signature.ImageUrl now breaks:


It was coding after 8PM, so I immediately started throwing more gasoline on the fire by compounding my mistakes.  I thought, heck, I need need 2 strings for the file – 1 that the GDI+ uses to write and 1 that the ASP:Image control can read from like this:

It worked, so I went to

String readFileName = String.Format("~/images/Signature.bmp");
String writeFleName = String.Format(@"C:\Users\Jamie\Desktop\Tff.SignatureCapture\Tff.SignatureCapture.WebForm\images\Signature.bmp");

bed, safe in the knowledge that I created a great solution:


Around 2 in the morning I woke up.  “You idiot” I thought.  The ASP.NET framework already has a provision to resolve relative and absolute paths.  It is the Server.MapPath function:

bitmap.Save(Server.MapPath(fileName), System.Drawing.Imaging.ImageFormat.Bmp);

Sure enough, that did the trick.  Since I was up a 2:15AM with my computer on, I decided to look at the ASP Image.Control to see if I could extend it to have an ImageStream function.


Sure enough, it is not sealed.  that might be a fun project for next week.  I went back to sleep, in a better place….

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: