I was trying to data bind a list of colors to a ComboBox and have the SelectedValue property bound to a particular color. The frustrating thing was that even though there was a color matching the “selected” color in the list, the ComboBox never had a selection when first displayed.

Eventually I discovered that my “selected” color was white (all color components at 255) while the list’s equivalent was Color.White. Careful reading of the Color.Equals documentation tells me that I was silly to think that white is white or black is black:

Black and FromArgb(0,0,0) are not considered equal, since Black is a named color and FromArgb(0,0,0) is not.

If you search the web for a solution, you might come up with a couple of proposed solutions:

• WinForms: How to create a control transparent to other controls – The official word from Microsoft, the solution is presented in several pages of poorly formatted VB code that makes you immediately want to look for something simpler, such as…
• C# Transparent Label (also referenced from Rick Strahl’s blog) – This solution is much simpler; it’s just a Control subclass that doesn’t paint a background and draws the label text in OnPaint.

After working with the second solution for a while, I discovered that it doesn’t handle updating the text very well. Just changing the Text property itself doesn’t do it, and if you invalidate the control, you get the new text painted over the old text. If you’re the kind of person who fusses about minutiae like legibility and such, this isn’t ideal.

So here’s a solution that has worked reasonably well for me, and that scores high marks in the simplicity category:

/// 
/// A label that is transparent.
/// 
public class TransparentLabel : Label
{
  /// 
  /// Paints the background with the parent's background image.
  /// 
  ///
e
  protected override void OnPaintBackground(PaintEventArgs e)
  {
    Rectangle rect = new Rectangle(Location, Size);
    e.Graphics.DrawImage(Parent.BackgroundImage, 0, 0, rect, GraphicsUnit.Pixel);
  }
}

It basically scoops up the correct part of the parent’s background image and uses it as the background for the control. Yes, it still isn’t transparency, just a much better job of “camouflage” than the default behavior. If you’re painting the parent’s background, with a gradient brush for example, you can paint that into a bitmap instead and set the parent’s BackgroundImage to the bitmap for this solution to still work.

public static GraphicsPath GetRoundedRectangle(Rectangle rect, int rad)
{
	int d = 2 * rad;
	System.Drawing.Drawing2D.GraphicsPath gp =
			new System.Drawing.Drawing2D.GraphicsPath();
 
	gp.AddArc(rect.X, rect.Y, d, d, 180, 90);
	gp.AddArc(rect.X + rect.Width - d, rect.Y, d, d, 270, 90);
	gp.AddArc(rect.X + rect.Width - d, rect.Y + rect.Height - d, d, d, 0, 90);
	gp.AddArc(rect.X, rect.Y + rect.Height - d, d, d, 90, 90);
	gp.AddLine(rect.X, rect.Y + rect.Height - d, rect.X, rect.Y + d / 2);
 
	return gp;
}

It’s trivial to convert that GraphicsPath to a Region — just call the appropriate Region constructor. You can then fill the region:

var path = GetRoundedRectangle(rect, 3);
e.Graphics.FillRegion(Brushes.Orange, new Region(path));

If your corner radius is sufficiently large, you might not notice anything wrong with the result. With a value of 3, it is pretty obvious:

The top left corner looks perfect:

The bottom right corner is decidedly un-round:

I started to wonder if all those round rectangle functions were wrong, but drawing the GraphicsPath itself shows that the code is correct:

The problem is that when converting the GraphicsPath to a Region, it uses the inside of the GraphicsPath, so you lose the outside pixels on the sides, which you can see when drawing the path and then filling the region:

It turns out to be a whole lot easier and effective to do a little p/invoke here:

[DllImport("gdi32.dll")]
static extern IntPtr CreateRoundRectRgn(int x1, int y1, int x2, int y2, int cx, int cy);
// ...
var region = Region.FromHrgn(CreateRoundRectRgn(rect.X, rect.Y, rect.X + rect.Width, rect.Y + rect.Height, 3, 3));
e.Graphics.FillRegion(Brushes.Orange, region);

Here’s the output from that code:

It looks like a little larger corner radius is needed to get the same rounding, but otherwise it is perfect.

The Future of C# (AKA C# 4)

Rob’s first presentation introduced what the C# team is working on for the next release of the language. A lot of the focus is around exposing support for dynamic programming and interoperability with dynamic languages like Python and Ruby. This is done by deferring the evaluation of method and property calls on some objects until runtime. At compile time, the normally strict static type checking of the C# compiler is relaxed when a method call doesn’t seem to exist in order to allow for the possibility that such a method will be added dynamically sometime during program execution. To indicate that this behavior is wanted, you use the dynamic keyword like this:

dynamic customer = GetCustomer();
Console.WriteLine(customer.FirstName);

At run time, whatever actual object is stored in “customer” needs to have a property “FirstName” or an exception is thrown. Otherwise, the actual type is unimportant. This is also known as “duck typing” where capabilities of objects are more important than actual types — if it looks like a duck and acts like a duck, it might as well be a duck.

Some people in attendance were confused about how the dynamic keyword differs from var. The var keyword really just saves keystrokes — the type is still static but figured out by the compiler. Objects that are dynamic however, have their method calls bound at run time.

The ability of C# to handle dynamic types also makes it easier to interoperate with Javascript. Rob showed a Silverlight application that called out to Javascript functions pretty much identically to calling regular C# methods.

The next version of C# will also have default and named parameters, which have been supported in other .NET languages, and will make COM interop a bit nicer. I’ve written a bunch of calls to Office where it seems like you’re passing in ten-thousand Type.Missing parameters to some of the methods, and that will no longer be required.

Silverlight Toolkit

Shawn Burke, one of the guys behind the AJAX Control Toolkit, is now heading a team to create Silverlight controls. This presentation showed the controls that they are working on, and described the distribution model.

The controls are things like AutoComplete, NumericUpDown, TreeView, DockPanel, WrapPanel, and others that would be really useful in building a typical modern GUI application. There is also charting support, which Rob said comes fairly mature by virtue of Microsoft’s assimilation of Dundas code and engineers. There is also support for theming applications.

The controls are to be released on CodePlex frequently, with some controls eventually making it into the official Silverlight SDK or even the Silverlight Core. The Silverlight Toolkit, not to be confused with a CodePlex project called the Silverlight Control Toolkit, has a nice sample application that shows off all the new components.

REST with WCF

My coworker, Ryan Jameson, went to a Microsoft event last year where the REST Starter Kit for WCF was one of the topics. He came back saying with a smirk that Microsoft had apparently invented REST, the way they had presented it. Rob implied no such thing, even joking that in every presentation about REST, there are people ranging from those who have never heard of it, to those that know Roy Fielding’s middle initial (which would be T, by the way).

REST is a philosophy for providing web services in a way that embraces the “way of the web”, such as:

• Most everything is addressable through a URI
• There are standard representation formats
• Interactions are stateless
• The HTTP protocol

Rob asked rhetorically if these principles might work OK given the success of the web, and summed up the philosophy by saying, “If you use GET for something other than getting a resource, you’re Part of the Problem.” And don’t even think about using POST to get something.

I haven’t done more than play around with web services, but it seemed to me that by using URI templates, WebGet and WebInvoke attributes, and WebProtocolException, you could suffuse a high degree of RESTiness into your WCF web service.

Things got pretty loose in this presentation, with Rob dodging pot shots about IE and standards conformance, switching to a Mexican accent for a bit of the delivery, and demonstrating that Notepad is a REST client. Kind of fun.

Azure

The last presentation was a lot to grasp, as Rob warned it would be. The denotation of “azure” is the blue of a clear or unclouded sky. But Microsoft’s Azure is about cloud computing. What does that mean?

Azure comprises a huge pile of stuff, which makes it pretty hard to talk about in a meaningful way. Hearing the presentation reminded me of when .NET was first announced. Everything at Microsoft was .NET then: Visual Studio .NET, Windows .NET, Clippy .NET, etc. The short version is that Azure combines typical operating system facilities with utility computing. In one sense it sounds like outsourced IT, where you let Microsoft worry about the data center, dynamically scaling resources as needed. But it is also more than that — an umbrella of networked stuff covering the “Live” services, SQL, raw data storage, and much more.

Rob says that Azure is Microsoft’s big bet right now. I wonder if things will settle down a bit when Microsoft gets a more fully-formed vision, much like they did with .NET.

Another useful tool for optimizing cold startup is Microsoft’s free CLR Profiler 2.0. While this tool has the aesthetics of a wadded-up paper sack, it does have the ability to graph each assembly that gets loaded, and the method that caused it to be loaded. This makes it easier to figure out why a particular assembly got loaded, allowing you to consider whether there might be a way to avoid loading it or postpone loading it until some less critical moment.

To generate the assembly graph, click the Start Application button in the profiler. It lets you browse to the executable, which it will then launch. When you close the application, the profiler displays a summary screen with a bunch of information about the managed heap and garbage collection. You can close that window. Instead, go to the main menu and pick View > Assembly Graph. You’ll see something like this:

Assembly Graph Window (click for larger image)

At the far left edge of the graph, you can see the total number of assemblies (30) that were loaded during the application run. The edges from there represent method calls that caused other assemblies to load. Underneath the method name is the total number assemblies loaded through the full call stack. As you move to the far right side of the graph, you eventually see each individual assembly that is loaded. If you click on a node in the graph it sort of highlights (is plaid technically a highlight color?) the edges in and out of the node. That can be really handy when the graph lines criss-cross over each other.

In my case, where I’m writing a Word add-in, I have some initialization that must happen on the main thread at startup. Other initialization is put on a low priority background thread, which allows Word to start up quickly while continuing to load up the add-in functionality for when it will be used. To get a better picture of startup, I commented out the background thread. Then I looked for call paths that loaded lots of assemblies to figure out if any of those could be deferred to the background thread.

I found that making an XML-RPC call was pretty expensive in terms of code loading. The RPC call itself was pretty fast — just talking to another process on the same machine, but it took loading classes from five additional assemblies just to make the call, which hurts cold startup performance. At this point we’re trying to figure out if the current performance is acceptable or if we need to tweak the add-in’s behavior a little to delay the RPC call to the background thread. 

Mr. Richter’s reason for disliking properties is that they look like fields but don’t behave like them, thus confusing developers. He gives a good list of ways in which properties are different from fields — think of all the ways that a zero argument method is different from a field and you’ll about have it — saying that those differences are bound to trip people up.

I disagree for a couple of reasons:

1. Properties are really pretty easy to grasp.
2. Most programmers adhere to the rule that all fields are private (which Mr. Richter also recommended), so there aren’t really fields to be confused by. Expect everything to be a method and you’ll generally be fine.

I say “generally” because there are some cases where the opposite is true: a property can behave more like a field than a method. For example, you can use the postfix increment operator on a property (that has both get and set accessors) and it behaves as it would on a field. That is, the operator gets the property value and sets the incremented value back in. [Added June 26, 2008]

A benefit of properties that isn’t really mentioned in the book is a more explicit (for lack of a better word) “bean-ness”. Java has the bean concept, where an object has get and set methods to create a set of properties, but the C# syntax is more elegant and apparent. With the explicit properties, you can do things like XML serialization, property editors, etc. with reasonable default behavior.

It’s probably true that .NET properties get abused and overused (see the official guidelines), but I still kind of like them.

First of all, it’s important to understand that the CLR itself loads up pretty fast. If you create “Hello, world”, even using Windows Forms, it starts almost instantly. As things get more complicated, though, you start loading more and more assemblies and classes, and the time to read all of those from disk (possibly combined with other I/O your application might do) is what makes cold startup so slow. If the application starts really fast on the next run, that’s because all of those assemblies and classes are cached, and physical disk reads aren’t necessary. 

I’m working on an add-in that runs in Word, Excel and PowerPoint. One of the objectives was to minimize the startup impact on the host application, so I started measuring it using an early implementation of the add-in. The results were not promising. On a low end machine, cold startup with the add-in took 18 seconds, compared to 8 seconds for the application without the add-in.

Performance Monitor has some useful counters for measuring your optimization. In my case, I added the .NET CLR Loading object’s “Total Assemblies” and “Total Classes Loaded” counters for WINWORD:

“Report” view is best for these. It just shows the plain numeric values of the counters. I discovered that I had 19 assemblies and 517 classes being loaded at startup. My strategy was to reduce those two numbers and hope that I’d see a corresponding improvement in startup time.

Next I used Visual Studio to debug the add-in, paying attention to the Modules window. This isn’t totally reliable in terms of figuring out what code loaded what modules since the debugger does things like call properties on objects while it is running, but it is still kind of useful. One thing jumped out at me right away. Even though I was running my add-in in Word, the interop assemblies for Excel and PowerPoint were also loaded. Looking at the code, I saw this:

Word.Application wordApp = hostApplicationObject as Word.Application;
if (wordApp != null)
{
  application = new WordApplication(wordApp);
  return;
} 
 
Excel.Application excelApp = hostApplicationObject as Excel.Application;
if (excelApp != null)
{
  application = new ExcelApplication(excelApp);
  return;
}  
 
PowerPoint.Application powerPointApp = hostApplicationObject as PowerPoint.Application;
if (powerPointApp != null)
{
  application = new PowerPointApplication(powerPointApp);
  return;
}
throw new NotSupportedException("Unsupported application");

Here the add-in is figuring out which application is running and initializing itself accordingly. The problem is that when the JIT compiler compiles the method with this code, it needs to load Word.Application, Excel.Application and PowerPoint.Application from the three interop assemblies.

I changed the code in two ways to fix this. First, instead of detecting the application by casting to the various Application objects, I used the name of the process. Second, I split the code that references each Application object into separate methods:

string processName = Process.GetCurrentProcess().ProcessName;  
 
switch (processName)
{
  case "WINWORD":
    GetWordObjects(ref application, ref uiManager);
    break;   
 
  case "EXCEL":
    GetExcelObjects(ref application, ref uiManager);
    break;  
 
case "POWERPNT":
    GetPowerPointObjects(ref application, ref uiManager);
    break;  
 
default:
    throw new NotSupportedException("Unsupported application: " + processName);
}

Another thing I discovered in the debugger is that the logger we’re using, NLog, has some pretty heavy initialization. Typical usage of NLog is to have a static member of a class like this:

private static Logger logger = LogManager.GetCurrentClassLogger();

The problem here is that the logger starts up at type initialization time, dragging in System.Configuration, System.Xml, System.Web (!?), System.KitchenSink, etc.

Instead of doing this, I created a property that would get the logger on demand, and then made sure that I didn’t log anything on startup unless I had to log an error. It wasn’t enough to just say, “Oh, this is just at DEBUG log level, so that’s OK.” If there was any logging, regardless of level, it would require that the logger be initialized even to figure out that it didn’t need to actually log anything.

I made a couple of other optimizations. First was to defer calling Application.EnableVisualStyles until after startup (a luxury for my situation since I didn’t have to show UI right away) which saved me from having to bring in System.Windows.Forms. Another was to avoid using Debug.Assert. In this case, at NextPage we have a “Verify” utility class in a common library that has similar functionality. Since I was already loading Common.dll, I used that instead.

After these changes, my performance counters showed 13 assemblies and 175 classes loaded. Word was now starting in just 11 seconds instead of 18 with the unoptimized add-in. There’s still potential for some more improvement, but that is good enough to let me continue with implementation without the fear that startup time would be unacceptable.

• You can search by class name (e.g. “OpusApp” for Word), but what if you somehow have multiple Word processes running? Which window do you get?
• You can search by window text, but it can be really hard to figure out what the window text is.
• You can set the Caption property on the Application object to some magic text and search for a window with the magic text, but Word throws all kinds of other stuff into the caption so this generally doesn’t work reliably.

Instead, if you’re using managed code, you can just do this:

IntPtr hwnd = Process.GetCurrentProcess().MainWindowHandle;

Underneath this uses EnumWindows and GetWindowThreadProcessId to find the right window.

There is a good article explaining the differences between the StringComparison enum values on MSDN. I’ll summarize here, but without mentioning the “IgnoreCase” variations in the enum since those are generally understood (though there are subtleties with case conversion). 

StringComparison.Ordinal is the best choice in most cases. When specified in comparison operations, these cause a character by character comparison based strictly on the numeric value of the characters. This has a couple of advantages:

1. It is very fast.
2. It is usually what you want.

The performance benefits include not needing to do any table lookups as well as the ability to fail fast if the two string lengths are not equal.

It generally only makes sense to use StringComparison.CurrentCulture if you are going to display the result of the operation to the user, such as in a list where the items are supposed to be sorted alphabetically according to the user’s culture. Instead of a character by character comparison, it is a “linguistic” comparison.

This leaves StringComparison.InvariantCulture. The author of the MSDN article was hard pressed to come up with a good reason for using StringComparison.InvariantCulture from .NET 2.0 forward. It does a linguistic comparison, but in a way that is always the same regardless of the current culture. In other words, it isn’t a character by character comparison, but it isn’t necessarily correct for the current culture either.

An example clarifies things:

static void Main(string[] args)
{
  Console.WriteLine("Grüße".EndsWith("sse", StringComparison.Ordinal));
  Console.WriteLine("Grüße".EndsWith("sse", StringComparison.CurrentCulture));
  Console.WriteLine("Grüße".EndsWith("sse", StringComparison.InvariantCulture));
  Console.WriteLine("Grüße".EndsWith("sse"));
}

This example uses the German ess-szet or sharp s character. In German, ß and ss are linguistically equivalent, so the results of running the program, even using the English (United States) culture, are:

False
True
True
True

If a user searched a document for “Grüsse”, it would be appropriate to show matches for both “Grüsse” and “Grüße”, and so use CurrentCulture. But for most other day-to-day string manipulations within code, such as comparing file names for equivalence, you should use one of the Ordinal values.

Both are valid (and distinct) file names, after all, which is not discernible using either CurrentCulture or InvariantCulture.

The path with the problem was something like this: \\qa\tests\۩۩۩۩۩

 The unusual character there is the Arabic symbol “Place of Sajdah” (U+06E9). For some reason, this path didn’t work correctly.

Ultimately, I tracked the problem down to a bit of code that was trying to test whether the path ended with a separator character, and if not, add one. It looked like this.

if (!path.EndsWith(Path.DirectorySeparatorChar.ToString()))
{
    path += Path.DirectorySeparatorChar;
}

This code wasn’t working as expected, so when the path was combined (using string concatenation) with a file name, the path separator was missing, which lead to the final symptom described by the defect. There are a couple of problems with this code.

1. System.IO.Path.Combine is the right way to merge paths where possible — you shouldn’t have to worry about whether there is a trailing slash or not
2. The simplest form of EndsWith (and StartsWith) doesn’t work as expected with roughly 20% of Unicode characters

Michael Kaplan explains that this is because many Unicode characters don’t have entries in the Windows sorting weight tables, and are therefore effectively invisible for some comparisons.

Surprisingly, @"\\qa\tests\۩۩۩۩۩".EndsWith(@"\") evaluates to true. All of the Place of Sajdah characters are “invisible” in terms of weight, and once you realize that, then obviously the string ends with a backslash. Also surprising is that all strings start with “۩”. That is, "Cheese".StartsWith("۩") evaluates to true. The string.Equals method and operator don’t have this problem, though, because they compare lengths before ever getting to the part where the Place of Sajdah characters would be thrown out of “۩۩۩Monkey۩۩۩” and thus become equal to “Monkey”.

The way to fix the problem is to use either StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase in the call to StartsWith or EndsWith. So the code snippet from above would work as expected when modified as follows:

if (!path.EndsWith(Path.DirectorySeparatorChar.ToString(), StringComparison.OrdinalIgnoreCase))
{
    path += Path.DirectorySeparatorChar;
}