public override RectangleF BoundingRect
{
  get
  {
    float x = WorldPos.X - (m_radius / 2.0f);
    float y = WorldPos.Y - (m_radius / 2.0f);
    return new RectangleF(x, y, m_radius, m_radius);
  }
}

I spent an hour this morning wondering why my mouse click code thought my circles were half as big as they were. Sigh.

public State FindByName(string name)
{
  foreach(State thisState in this.StateList)
  {
    if (string.Compare(thisState.Name, name) == 0)
    {
      return thisState;
    }
  }
  return null;
}

New Hotness:

public State FindByName(string name)
{
  return States.Find(
    state => (string.Compare(state.Name, name) == 0)
  );
}

Sweet sweet syntactic sugar!

System.InvalidOperationException: There was an error generating the XML document. System.InvalidOperationException: The type was not expected. Use the XmlInclude or SoapInclude attribute to specify types that are not known statically.

But, even after I put in the XmlIncludes, OR when using the serializer constructor overload that takes a list of types, I was still getting the error.

Turns out my problem, strangely, was this line:

[XmlRootAttribute(
  "Document",
  Namespace = "http://www.cuttlefishindustries.com/mycoolnamespace",
  IsNullable = false)]

I didn’t investigate it that much but it appears that if you specify a Namespace, the serializer ignores the additional types you supply (either via XmlInclude or the constructor overload). Once I took out my document’s XML root attribute, my serializer worked. Huh. So, there ya go, hopefully this’ll save someone some time, sometime.

*** READ THE COMMENTS! I have been enlightened. ***

Maybe it’s just me, but it took me forever to figure out how to set the background color of a control to the “window” color the user has set up in the control panel. 99% of the time this is white but since I’m one of those guys who runs with dark window colors, I was determined not to make that assumption and do things the right way.

Ways you can’t do it:

• System.Windows.Forms.SystemInformation: You can get a wealth of information from here, including whether or not the user has chosen to always show pull-down menu access key underlines, or only when ALT is held… but no color information. Close, but no cigar.
• Color.System.: all the other colors live here. I was hoping for a “System…” subsection under here or at least names like “ActiveBorder” intermingled with “hard coded” names (Lemon Chiffon!), but couldn’t find any.
• Control.DefaultBackColor: So close! This appears to return the 3D face color, but regardless isn’t what I was looking for. I want a big list of all the system colors, not just a one-off.

The Way:

System colors, in C#, are called “known colors.” Once you know this it’s easy to find:

System.Drawing.Color.FromKnownColor(KnownColor.Window);

And, as you’d expect, the KnownColor enumeration contains all of the other user-definable colors (active window border, whatever).

I don’t understand the logic behind calling these colors “known colors.” If anything, Lemon Chiffon is a Known Color (well, OK maybe not to all of us, but to interior decorators at least), and the current window color is Unknown, or at least “user-defined.” But even more perplexing is why C# deviates from calling them “system colors.” In Win32 you’d call GetSysColor() (and truth be told, I almost just pinvoked that). KnownColors is a wart that detracts from the beautiful organization of C# in other places (for example, Process or System.IO.Ports).

If I were running the C# show, I would have put the system colors in with the rest of the system information.

The top line is where I start the build, and the bottom line is the first error from the complation. But everything in between is completely useless. Specifically it looks like an echo of the command line for the C# compiler (csc) – the bulk of which is just all the CS files to compile.

That’s annoying, but what’s worse is that when you hit F4 to go to your first error the IDE takes you to this line instead. This morning, after working in c# for almost 3 years, for some reason, I just couldn’t take it anymore.

As it turns out the “magic option” is here:

By default the “MSBuild Project Build Output Verbosity” setting is “Minimal,” which for me isn’t nearly minimal enough. Set it to Quiet and behold:

I am kind of terrified to see what the “Diagnostic” setting would do to my poor output window.