GDI and Ampersand Rendering

Yesterday I spent a while tracking down a bug in a library that I wrote a while back. One of the things that the library is used for is drawing text in fonts that aren't web safe to be used as headings and whatnot. So if I want the phrase "Out Of Office" drawn in whatever font I just created (this isn't actually a real use case) I can just upload the ttf file to my fonts directory on the server and use the control to generate an image dynamically that will fit the space. The tool even provides caching so after a string with a given set of params has been requested N times it caches it and will load the image from the cache upon future requests. But enough about that.

The bug I tracked down yesterday was related to the ampersand character and the fact that for some reason when the string I wanted to draw contained the ampersand character then no text was being drawn. I wouldn't get any exceptions or anything I just wouldn't get any text. The result image was just the background color I'd requested the size that the text would require if it was in the image. Without the ampersand char it worked as expected.

In GDI when you go to draw a string via Graphics.DrawString you can optionally display hot keys (meaning underlining a specific key to specify that it's a shortcut visually). When I'm drawing a string I'm passing in a StringFormat object which contains some formatting information (horizontal alignment and such). One of the properties of StringFormat is HotkeyPrefix which is used to set the Hotkey functionality for the string (Hide, Show, or None). Now you might think that simply setting it to None (which is the default btw) would result in no Hotkey formatting being considered when rendering the string. But you'd be wrong.

After a great deal of trial and error I got the ampersand to render when I replaced each ampersand with 2 ampersands (an escape of sorts) and then set HotkeyPrefix to Hide. Why this worked I'm not sure and it's kind of counterintuitive but whatever. That's how I fixed it.

You know the fun Restart Now/Restart Later Windows pop-up that shows up when you have updates that you need to install? The one where if you click later it will just pop up again in a few minutes? I'm term serv'ed into a server that I don't have administrator rights on and it popped up. Only since I don't have shutdown/restart rights the restart button is grayed out. Since I have no choice in the matter why does the freakin thing even show up?

So I just drag the little window off to the edge of the screen where it will sit quietly and not bother anyone anymore.

The Excel Interop

I just finished up a project working on a win32 client application that is used to import data from an Excel spreadsheet into a database via a secure web service. Working with the interop was interesting and it was nice to get exposed to something new. I'll post more about web services later (as well as returning custom data types via web service methods, serializable Dictionary objects, and converting rtf to html) but I wanted to rant about the Excel Interop a bit.

Indexing
When I started working with the interop I went in and created an instance of Excel:

Microsoft.Office.Interop.Excel.Application excelObj = new Microsoft.Office.Interop.Excel.Application();


This is all well and good. After that I set visible to false and went about starting to access some of the bits and pieces in my xls file. Oh, and because we're using C# and because Open isn't overloaded:

Microsoft.Office.Interop.Excel.Workbook workbook = excelObj.Workbooks.Open(
filename,
Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value,
Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value,
Missing.Value, Missing.Value, Missing.Value, Missing.Value
);

Microsoft.Office.Interop.Excel.Sheets sheets = workbook.Worksheets;
Microsoft.Office.Interop.Excel.Worksheet worksheet = (Microsoft.Office.Interop.Excel.Worksheet)sheets.get_Item(0);

Now, if you run this code you'll get an exception citing an invalid index:

System.Runtime.InteropServices.COMException (0x8002000B): Invalid index

If you're like me you'll immediately try starting your index off at 1 because I suppose it makes sense to start off your worksheets at 1. As much as this seems like VB and as much as I don't like VB I think I can live with it. So you change the sheet number to one and go on your merry way.

Then you try to access some data in your first worksheet:

string str = (string)((Microsoft.Office.Interop.Excel.Range)worksheet.Cells[0, 0]).Value2;

Running this code gives you an exception and you want to assume it's because you started your indices off at 0 but it doesn't quite make sense because it gave you a different exception:
System.Runtime.InteropServices.COMException (0x800A03EC): Exception from HRESULT

Hopefully at this point you immediately try Cells[1, 1] and don't spend some time trying to figure out what you did to go from a meaningful exception that made sense to a generic COM Exception. If you try 1,1 you'll find that it works and all will be right in the world.

What bothers me about this isn't the fact that I have to start the index off at 1 rather than 0. What bothers me is that when I tried to open a worksheet with an out of bounds index I got an exception telling me that it was an index issue. When I tried cells that were out of bounds I got a generic exception. The worksheet exception was actually helpful and immediately let me know what the problem was whereas the cell exception wasn't even though it was pretty much the same exact issue.

Killing Your Instance:
I'm not even going to into detail on this as it's been beaten to death already. Killing off an instance of Excel is a pain though I don't think that's really the fault of the interop. You have COM to thank for that one. Essentially you have to make sure that for each Excel COM object you create you're calling ReleaseComObject:

Marshal.ReleaseComObject(excelObj);

And then calling the Garbage Collector:

GC.GetTotalMemory(false);
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.GetTotalMemory(true);

I'm not really one to talk in this instance though since my client app still has a bug where when multiple instances of the Excel application are created once I close them out all of the processes go away except for the first one I created. It's really bizarre. See the references section for some links.

Hyperlinks
This isn't so much a beef with the Excel Interop as it is with Excel in general. In Excel you can't have a link within a cell. You can have the entire cell be a link to some location but you can't have the text "click HERE for pictures of my cat" and have only the text "HERE" act as a hyperlink. This ended up saving me some time on the rtf to html conversion but is kind of lame in my opinion.

References:
Here are some of the pages that I found the most helpful when working through this:
- MSDN: Excel Tasks
- Craig Murphy: Excel Interop - killing Excel.exe
- MS Help and Support: Office application does not quit after automation from Visual Studio .NET client
Excel Solutions Forum