Good article. I, however, prefer to create a "bag"--a simple struct--to hold state when I'm using Control State with an inherited control. It makes my code a bit easier to understand and maintain than sticking my variables into an array of objects. Check it out--which is easier to understand and is less likely to be buggy:
private struct ControlState{public int myIndex; public bool selected; public object baseState}
-- or --
object [] stateArray { myIndex, selected, baseState }

With a state array, you may get your states out of order, which can never happen with a strongly typed struct. Plus its got an obvious flag that says "hey, don't forget about the base state!", and you can do initialization of variables etc etc etc.

Interesting! I like that approach. The reason I use an array is because it appears to be the convention. If you follow the convention, it just works.

However, with your approach, if I follow the convention, I'll get a runtime error. But, I'll see the BaseState property and hopefully figure it out and do it the right way. That's a real nice benefit of your approach. It's strongly typed and forces me to do the right thing. Well done!