Monday, March 17, 2008

Welcome Susan!

Susan


At a little before 11AM on March 15th, Wangdera Corporation welcomed its newest employee when our daughter Susan was born at our home in Virginia. Susan tipped the scales at a hefty 8 pounds, 14 ounces (4.03kg), and she and her mother are both doing extremely well. Big sister Ellen is very happy and proud as well.


More pictures available at our Flickr site.


In what may be a related event, Ellen has announced that she is changing her name to "Princess Ellen Ladybug".


Wednesday, March 12, 2008

Art Geek Zoo

At our house, the newspaper gets full coverage: I read only the comics and my wife reads everything else. I like comics. So I thought it was pretty cool when I found out my good friend Rob Stenzinger has started to publish Art Geek Zoo, his latest artistic effort, online. Check it out!

 

Tuesday, March 11, 2008

My First Trademark Violation

A few weeks ago, I posted a pair of little utilities that I wrote to help me play Falcon. They were just one of those spare-time, throwaway things most programmers do from time to time, so I didn't put a ton of thought into them. Well, last week, I got a phone call from a marketing guy at Sassafras Software…it seems I should have put a bit more though into at least the names.

 

See, one of the bits I published, I called KeyServer. I called it that because it's a little TCP listener that receives events and sends keystrokes to the active application. Of course, it's also a registered trademark of Sassafras Software. Oopsie.

 

The marketing guy was pretty nice about it. He never said anything about legal action. But here's the thing: US Trademark law says you have to actively defend a trademark, or you lose it. That means that if you don't sue the people who use your trademark, a competitor can come along and point to that behavior as proof that you don't want your trademark and that it should be taken away.

 

On the one hand, it was somewhat shortsighted of me to name my software "KeyServer". I mean, that was practically guaranteed to be trademarked. On the other hand - subjectively and emotionally - it's never fun to be threatened with legal action, even when it's done politely and when you know that the person delivering the news has no choice about it. Lesson learned, I guess.

 

On the bright side, it was good motivation to add a few features that I've been meaning to get around to. So I'm re-releasing the software under the name "Keylay" (it's a keystroke relayer - get it?). Here are the new features:

 


  • A name that won't get me sued!

  • Has a less-boring tray icon that changes colors based on whether or not a profile is loaded, whether or not a client is connected, and animates when keystrokes are being relayed.

  • Takes a command-line argument that is the path to a profile to be loaded at startup.

 

While I was at it, I also updated F4Panel a bit. In addition to the ICP and the MFDs, I also added an "Aux1" panel that gives access to touchscreen controls of a few miscellaneous things like landing gear, the autopilot, the ECM and RWR, the laser, and the master arm switch. In addition, I made it remember the last address it connected to, since that was driving me nuts.

 

You can download the updated binaries and the source here.

Friday, March 7, 2008

DebuggerStepThroughAttribute

Here's a good one I was reminded of the other day. I was writing some code of the form we've all seen a thousand times before:

 

public Foo Bar {
  get { return _bar; }
  set { _bar = value; }
}

 

Even with automatic properties in the latest version of C#, you still wind up writing code like this a lot. Unless you're fortunate enough to be writing code in a more advanced language…like Lisp. :) (Sorry, had to.)

 

Normally this is no big deal, but there is one time where this construct can get really annoying: when you're debugging and the property is frequently accessed as the means to get somewhere else. In my code that will often look like this:

 

public SomethingProvider SomethingProvider {
  get { return _somethingProvider; }
}

 

when I have some service that I've abstracted, maybe to make testing easier. As a result, my code has lots of calls in it like this:

 

SomethingProvider.PerformOperation(arg1, arg2, …);

 

When I hit that line, I want to debug into it, but of course when I hit "step into" I wind up on the property accessor. It's even worse when there are multiple properties involved, as for example in code like this:

 

SomethingProvider.PerformOperation(OtherProvider.RetrieveValue(), YetAnotherProvider.Calculate());

 

By the time I've finished stepping in and out of that, I'm all, "Aargh! Just take me to the code!" Luckily, there's an attribute that lets you skip all these piddly statements: DebuggerStepThroughAttribute. You use it like any other attribute - apply it to a method, a whole class, or a property accessor. Note that you can't apply it to a property as a whole - it has to go on the individual getters or settors, like so:

 

public SomethingProvider SomethingProvider {
  [DebuggerStepThrough]
  get { return _somethingProvider; }
}

 

Put enough of these in and stepping in to a compound expression becomes much less tedious. Yay!

 

I don't think I'd recommend generally putting this attribute on anything but simple one-line properties of the form I've shown here, and even then you want to be careful: debugging is complicated, and I know I can screw up even simple property access - sometimes stepping into those things is actually useful, as it shows you that you cut and pasted one too many times and wound up returning the wrong value.

 

That said, you can still set breakpoints on code you've applied the attribute to, and the breakpoints will still fire.