Random header image... Refresh for more!

Posts from — October 2009

Read The Health Care Bills

The competing health care bills are now available on the Internet.  Read them and decide which one you like.

The Democratic Health Care Bill is almost 2000 pages long, providing comprehensive changes and reforms to all parts of the system.

The Republican Health Care Bill reflects more Republican values of small government and non-interference in the free market.  It is a much slimmer 520 pages long and does not contain the kind of sweeping reforms that the Democrats have put forward.

October 30, 2009   No Comments


I seem to have been neglecting this lately.  I’m a week overdue on a programming/testing post, and it’s almost getting to the point where I’m late on a video game history lesson.  So, to prove I’m not dead, here’s a few bits of here and there.

First, if you’re in Washington, you have less than a week left to Approve Refererendum 71.  I already have.  Have you?

Now, back to games and things.  Here’s a few of my latest acquisitions.


This one should require no introduction or explanation.  Tengen Tetris.  I spoke about this game several times in previous entries, alluding to the legal fight between Atari and Nintendo, but always in passing.  Now that I actually have a copy, I’ll have to devote an entire article about it.  That’ll be in the future, but for now, to illustrate its awesomeness:  Two-Player Cooperative Mode.


The second notable acquisition is a Japanese Famicom game called Metafight.  Well, it’s actually “Something-Something Metafight”, but I don’t know Japanese.  The cover has some generic anime characters, one of which looks angry.  None of that really matters.  I’m not really into Japanese things and I’m not really into anime or stuff like that.  And I don’t have a Famicom system.  So, then, you ask, why would I go out of my way to buy a Japanese anime game for the Famicom?


This screenshot might help you figure it out.  It at least might look a bit familiar to you.  Maybe.  Can’t quite place it?  This’ll do it:


Metafight is the Japanese version of Blaster Master.1  There is no opening story sequence in Metafight, which automatically means that the plot for Metafight makes far, far more sense than the “My pet frog jumped on a box of radioactive waste in my backyard and went down a hole and I followed it and found this bad-ass hyper-agile tank in the underworld and I proceeded to fight lots of nasty creatures in my bad-ass hyper-agile tank in order to rescue my radioactive mutant pet frog and save the world from the radioactive mutants that live under the Earth’s crust” plot that Blaster Master tried to have.  Of course, since Blaster Master changed the story from whatever angry anime guy was doing to something stupid about a mutated frog, they had to change the tank ignition sequence to be in a cave, instead of Metafight’s futuristic tank garage.

But enough about that for today.  It’s time for robots.

It’s been a while since I’ve visited the land of the video game playing robots, but I assure you, I have been thinking about them.  I think the next time I get back into them, assuming I ever do, the first thing I’ll do is organize the codebase.  It was built to get it to market, but not built for future expansion.  If I want to keep going with this, I’ll need to rewrite large sections of it and separate the movement interface and screen capture plumbing from the game specific recognition and logic code.  Although it won’t be quick, that should hopefully be reasonably straightforward to do.  From there, I’d like to work on improving the control of the paddle.  A few weeks ago, I think I may have improved the precision of the controls, but I still haven’t tested it out.

At any rate, I think Pong is the wrong game to try to develop precision controls.  The trajectory projection gets in the way of making sure the paddle is moving exactly where I want it to go as fast as I can get it there.  The paddle might very well be going where I want it, but by the time it gets there, that’s no longer where I want it.  So, I think I’m going to have to try another game to tune the paddle controls.  Right now, I’m leaning toward Kaboom! as the game of choice.  It should have easy to program recognition and logic (Bomb drops straight down, move to catch bomb, repeat), and it will absolutely require precision, accuracy, and speed.  Runner up is Indy 500, but I think the pathfinding and collision avoidance knock that one out at this point, not to mention the 360 degree driving paddle.  An interesting side-note is that pretty much whatever paddle game I choose, I’ll have to deal with something I didn’t care about in Pong:  The button.

Beyond the paddle, to really get things done on the Atari 2600, I’m going to need to be able to control a joystick.  I have several options, of course.  I can try some alternative controller, like the button operated Starplex or the gravity operated LeStick, but really, or maybe try to build my own controller, but really, to claim that I built a robot that can play an Atari 2600, I have to build something to handle a good old CX40 Atari Joystick.  That’s probably not going to be easy.  The controls won’t have to be as precise as the paddle, since there’s only nine options, however, it’s going to involve control on two axes that are somewhat dependent on one another.  I’ve had thoughts involving double arms that push or pull, a swing arm with a piston, a gantry crane like setup, and something that rotates and can push the stick, and none of those ideas seem any good at all.  I’m sure I’ll think of something.

  1. And if you don’t know what Blaster Master is, well, you just need to play more NES games. []

October 27, 2009   1 Comment

Electric Curiosities: Pac-Man vs. K.C. Munchkin

The game is familiar.  You play a round creature that lives in a maze.  You’re chased by monsters and have to eat dots to survive.  Some of the dots let you attack the monsters temporarily.  When you get all the dots, the maze resets at a higher speed.  It’s a lot like Pac-Man, but it isn’t.  The game is K.C. Munchkin, and you’ve probably never heard of it, let alone played it.

If you have heard of K.C. Munchkin, then it’s probably because of the lawsuit.

Back in the early 80s, a widespread and highly contagious disease known as “Pac-Man Fever” infected millions of people around the world.  The only known cure for this pandemic was to eat lots of dots, power pellets, and ghosts in your local restaurant, bar, convenience store, or darkened rooms where people repeatedly paid good money to stand in front of a TV for five minutes, known as “arcades”. 1  Eager to help fight the spread of this horrifying condition, Atari, who was the leading video game manufacturer at the time decided to help sufferers of Pac-Man Fever get their treatment in the convenience of their own home, and purchased the exclusive rights to develop and distribute a home version of the cure.

Obviously, this was a big deal for Atari, who was starting to get a bit of competition in the home console market.  Most of it was weak and incapable of causing any harm, but some of it, like the Intellivision, constituted a clear and present danger.  By grabbing the license to the biggest video game in the history of video games2, they grabbed a license to print money.  Not only would the Atari 2600 have a sure-fire hit, their under development Atari 5200 console would have a sure-fire hit, their computer line would have a sure-fire hit, and, on top of that, the Intellivision would have a sure-fire hit, because Atari put profits before console exclusivity.  To summarize, Pac-Man == $$$.

Naturally, mega hits will spawn imitators.  Magnavox, the makers of the Odyssey2 system, which was one of the legitimate competitors to Atari3 decided to produce a Pac-Man imitator.  However, since it was clear that a straight Pac-Man ripoff would get them sued, they made some changes to the game play.  Keep the maze, but make change.  Keep the big round chomping critter, but make it blue and give it antennae and a smile.  Keep the creatures that chase you, but only include three of them and make them look like aliens.  Keep the dots and power pellets, but have far fewer of them, and, most importantly, make them move.  Throw in multiple mazes, invisible mazes, and a maze editor.

And one more thing, release it first.

Here is a leaked photograph of Atari executives at the very moment that they heard about K.C. Munchkin:

Scared Blue Ghosts

Pac-Man == $$$.  Threat To $$$ == Lawyers.

Atari sued to halt distribution, claiming copyright infringement.  K.C. Munchkin was clearly inspired by Pac-Man, and the differences clearly show that Magnavox knew that they were stealing.  Atari lost.  Although there were similarities, the court reasoned, there was nothing directly stolen and any reasonable person looking at both works could easily tell that they were different.

But remember, Pac-Man == $$$.  Threat To $$$ == Lawyers.

Yep, Atari didn’t go down that easily.  They appealed and this time, they won.  K.C. Munchkin was pulled from the shelves, Atari was free to make millions from the distribution of home versions of Pac-Man, and Atari, Inc. v. North American Philips Consumer Elecs. Corp. entered into court precedents.

The thing I don’t understand about all this is how this lawsuit didn’t completely devestate the video game market permanently.  As I’ll talk about, K.C. Munchkin is clearly not Pac-Man, but it is clearly Pac-Man like.  But the same holds true for many games.  The industry is founded on imitation.  Sonic stole from Mario and Mario stole from Pitfall.  Gradius is Space Invaders moving forward.  There are hundreds of Doom clones and GTA clones.  And I can’t even tell the difference between Guitar Hero and Rock Band.  All of these knock-offs should have been destroyed by the precedent set by the lawsuit, but it never seems to get used.  In fact, I don’t think Magnavox was sued for their Breakout clones Blockout/Breakdown or their Space Invaders clone Alien Invaders – Plus!4 or their Outlaw clone Showdown in 2100 AD or their Street Racer clone Speedway or their Indy 500 clone Spin-Out or…  The list can go on.  Why, then, was K.C. Munchkin singled out for the attack?


Magnavox did it first, and, more importantly, Magnavox did it better. 5 The existence of K.C. Munchkin was an embarassment to Atari.  It was not a real threat to Atari.  Atari was guaranteed to make bucketloads of money with the Pac-Man license, and K.C. Munchkin on its own wouldn’t have put a dent in it.  However, because Atari was guaranteed to make bucketloads of money with Pac-Man, they wanted it fast, they didn’t care about getting it right.  I’m not going to say that Pac-Man for the Atari 2600 was an unmitigated disaster of a game, because it’s not.  As far as Atari games go, it’s not that bad.  Where it fails is in the comparison to the arcade version.  It’s blocky, the ghosts are all the same color and they flicker, the colors are all wrong, the sound is horrible, the maze is different, there’s a weird rectangle instead of fruit.  It’s like ordering a reproduction of the Mona Lisa and getting a crayon drawing from a six year old instead.  It’s just disappointing.  So to have K.C. Munchkin laughing from the sidelines, where a third-rate competitor one upped the official licensee, with its multi-colored non-flickering enemies, its decent sound and its sharper graphics, that was intolerable.  If the Atari 2600 of Pac-Man version had been a closer replica of the arcade game and had it come out first, Atari probably would have left K.C. alone and that game wouldn’t be remembered for anything today.

So, then, let’s take a look at the legendary K.C. Munchkin for the Magnavox Odyssey2 and how it compares to the infamous Pac-Man for the Atari 2600.




Straight away, it’s clear that KC Munchkin is not Pac-Man.  You would not have seen this game in a store and mistakenly believed that you were buying Pac-Man.  From the front, it’s hard to even tell that the game is Pac-Man like.  I do have to give KC Munchkin (And Odyssey2 games in general) bonus points for their box art, which always looks like it should be painted on velvet and viewed under a black light.  Bizarre smiling shaggy things and glowing cubes, and the wooshing Odyssey2 logo ruling over all.

Pac-Man, on the other hand, just looks like the game.  It’s really boring, by Atari standards.  Usually the box art is so fanciful and wild that it barely resembles anything remotely related to the game inside, but for Pac-Man, it looks like the game.  Even worse, it looks like the Atari 2600 version of the game, not like the arcade version.  Consumers should have known what they were in for when they saw it.  Somewhat mysteriously, the large Pac-Man figure on the outside of the box looks nothing like the cartoony Pac-Man that’s on the cartridge itself.  I don’t know of any other Atari game where the box art is different from the label art like that.

As far as the back of the boxes go,  KC promises multiple mazes, invisible challenge mazes, and a maze editor.  Pac-Man promises …  a children’s mode.


While KC Munchkin wins on the packaging, Pac-Man wins on the instruction manual front.  Inside the Pac-Man manual are detailed and whimsical drawings of the characters and items in the game.  Inside KC Munchkin’s official rules book is difficult to read white text on a black background, surrounded by game sprites and random numbers and letters, some of which have inexplicable Superman trails.  I think the glowing question mark sums up the KC Munchkin instruction book.



The Pac-Man playfield just looks sickly.  Blue and kinda sickly yellow.  Really?   The arcade game was blue walls on a back background.  The Atari is capable of producing the colors blue and black.  So why the change?  Even Pac-Man looks queasy in that environment.  K.C. Munchkin, however, has bold purple walls on a black background.  Easy to see, and look how happy KC is as he6 strolls around the maze.  The Pac-Man maze is a symmetrical, rectangular affair, without the twists and turns of the original.  KC lives in an asymmetrical tangle of passageways, forcing you to develop different strategies for the left or the right of the board.

If you look at the Pac-Man shot, you’ll see that there are only two ghosts and only two power pills.  That’s because the ghosts and power pills flicker like mad because the Atari has limited sprite capabilities.  The programmer actually only displayed one ghost every frame, and it just looked like four because the other ghosts hadn’t faded from the CRT yet.  They’re all the same color because he was lazy.  Unfortunately, the all digital PC input device I’m using captures frames as they are.  I recorded at 30 FPS, which means that I got two frames of the Atari screen, therefore two ghosts.  There really are four ghosts and four pills. For the KC shot, what you see is really what’s there.  Three creatures, each of a different color, and four special munchies.  The special munchies will flash to an X every once in a while, so you can easily tell what they are, but that’s the only flickering you’ll get in this game.

The KC characters are more detailed.  They have more visible features and have distinct up and down animations, as well as left/right.  Pac-Man is always in profile and the ghosts never look like they’re moving in any particular direction.

And then there’s the dots.  The dots are really what makes K.C. Munchkin stand out.  Most Pac-Man based games are full of dots.  They’re everywhere, and you have to go everywhere to get them.  Not so in K.C. Munchkin.  In this game, there are only twelve dots.  Four power dots and eight regular dots.  The catch?  The dots move.  That one little feature is what makes K.C. Munchkin be powered by awesome.  Not only do you have to run away from the monsters, you have to chase down the dots.  At first, they’re lethargic, but as you eat their brothers and sisters, they become less complacent and more alert, until the last remaining dot is hauling ass at the same speed you move through the maze.  You have to plan ahead to cut it off, while at the same time, you have to make sure you’re not being drawn into an ambush by the three critters.

Another major difference in the gameplay of KC Munchkin is that you only get one life.  It’s a theme that runs through many Odyssey2 games7.  One life, no bonus lives.  Your score is only as good as your best run.  Make one mistake, and you’re back at zero.  It’s a bit disconcerting at first, but it ends up working to the advantage of the game.  Your near death scrapes with the red critter as you hunt down that last dot are made much more tense and exciting by the fact that you don’t get to try again.

Pac-Man Audio | K.C. Munchkin! Audio

And finally, the sound.  Pac-Man is about as pleasant to listen to as a trash compactor.  Every dot you eat sounds like an electric banjo being massacred, the death sound and start game sound are just grating.  Only the power pellet and eating ghost effects are remotely pleasant to listen to.  None of them sound anywhere remotely like the arcade sound effects.  The programmer didn’t even try.  K.C. Munchkin has a considerably mellower sound.  It’s still early home console sound, so it’s not all that great, but it won’t have you reaching for the mute button and a pack of earplugs to block out the horror while you play.

Of course, all that text and all those pictures don’t really mean much.  You have to see the games in action to truly compare them.

What came next?  Well, Pac-Man obviously continued on his path of fame and fortune and is still making games today.  On the Atari 2600 front, Ms. Pac-Man was released a few years later and was simply awesome, fixing pretty much everything that went wrong with the original.  Fame, however, was not in store for K.C. Munchkin.  He starred in one other game, called “K.C.’s Krazy Chase”, which was a semi-autobiographical depiction of his legal battles.  Afterward, he retired from the video game scene, and is now a veterinarian in Upstate New York.

Bottom Line:  If you’re a hard-core dot munching Pac-Fan or if you are considering buying an Odyssey2 system for your collection, you need to get a copy of K.C. Munchkin.  If you already have an Odyssey2 system and don’t have this game, there is something wrong with you.  If you’re a more casual fan, not willing to drop $100 on a 30 year old console just to play this one game, then there might be emulators or Flash versions available.  I’ve never bothered to look, since I have the real thing.

  1. Sadly, arcades are now thought to be extinct in the wild.  The last non-captive arcade died in late 1994, in Burlington, WA, when it was eaten by a Seattle’s Best Coffee. []
  2. Which, of course, was only about ten years at the time… []
  3. And by “legitimate competitor”, I mean that it had measurable market share, a decent library of games, and had survived for more than a year.  You may not have heard of this console, but it did exist.  Honest. []
  4. Where Plus == Suck []
  5. See also the lockout chip lawsuit that Nintendo filed against Tengen/Atari when Tengen released a better version of Tetris than the Nintendo one… []
  6. He?  I don’t know.  I suspect that KC is pulling a Samus on us. []
  7. Probably unsurprisingly, since half of them were written by one guy. []

October 18, 2009   2 Comments

SWA in WPF and Silverlight

A couple of weeks ago, I wrote about using the System.Windows.Automation libraries in the .Net Framework to write UI Automation, primarily for use in writing automated test cases.  Well, that’s only half the story.  In order to truly unlock the power of SWA and the UIAutomation library, you’ll want to add SWA instrumentation to your application.  It’s not required for using SWA, but believe me, it will make your testers happier.

Microsoft has provided a way to add enhanced support for UIA into Win32 and Windows Forms apps, but WPF and Silverlight have been built from the ground up to have full and simple support for the UI Automation properies.  In this post, I’ll be exploring how to instrument a Silverlight application, largely because I can give a link to my finished sample app for you to explore.  Working with WPF should be mostly the same. 1

Let’s start by looking at what you get from Silverlight, straight out of the box.  We’ll begin with a simple text box and button, the sort of thing you’ll find in pretty much any UI program ever written.

<StackPanel x:Name="LayoutRoot" Orientation="Horizontal" Width="250" Height="32">
    <TextBox x:Name="TextEntryBox" Width="150"/>
    <Button x:Name="SubmitButton" Content="Submit"/>

That produces a super exciting display that looks like this:


I has mad UX skillz.  Fear them.

If you open good old trusty UISpy and examine the control tree of your XAML masterpiece, you’ll find something that looks a bit like this:


An “edit” control and a “button” control in a Silverlight Control?  That looks an awful lot like what we just wrote up in XAML, doesn’t it?  That’s because it is.  Yep.  You write it and presto, it’s seen by SWA.  And if you look at the automation properties panel in UISpy, you’ll see that the edit control has an AutomationId with the value of “TextEntryBox” and that the button control has an AutomationId of “”SubmitButton”.  Those are also what we put in the x:Name attributes back in the XAML.  In other words, for Silverlight and WPF apps, most of your controls will automatically be exposed to UIAutomation using the programmatic names you’ve already given them in your code.  You get that for free.

But wait!  There’s more!

Do you see all those other properties in UISpy?  Well, if you don’t, here’s a screenshot for your enlightenment:


Well, you have direct access to set some of them straight from XAML.  Okay, so it’s not completely free, but it’s still really really easy.  They’re exposed through the AutomationProperties attribute.  As an example, let’s set the “Name” property of the text box in the sample.  If you look at the UISpy control tree, you’ll see that it’s called “”, instead of anything useful.  The automatic population of the “Name” property usually uses the content of a control.  In the case of the button, it has a text label of “Submit”, which is where it gets the name from.  But the text box doesn’t have any content, so it gets left out.  Let’s give it a name before it gets depressed.

<TextBox x:Name="TextEntryBox" Width="150" AutomationProperties.Name="Search Query"/>

All it needs is that “AutomationProperties.Name” attribute set and there you have it.  our edit box is now showing up with a name in UISpy and everyone’s happy.


Most of the time, I’ll stick to “Name” and “AutomationId” for helping me find elements for my automated tests.

For a good number of decently simple applications, that’s all you’ll need to know.  For that reason, most tutorials I’ve seen on the subject stop here and pretend that this much information is actually adequate for using SWA in the real world.  I, however, have actually done some work in the real world and know that this alone can be painful to work with.  So, I’m going to keep rambling for a bit.

Consider, for a moment, that you’ve assembled some combination of controls that is useful to you, and that you’d like to reuse that combination of controls and not have to copy/paste/rename.  Now, I understand that many of you will never attempt something as wild and complex as this, and that the thought of it alone might drive you to madness, but please bear with me, as it’s required for my next demonstration.  For the sake of conversation, let’s say that this useful combination of controls is a text box and a button to go with it.

So, you have a user control with a box and a button.  I’ve given it the bleedingly obvious name of “BoxAndButton”.  This code should look familar to you:

<UserControl x:Class="SWASilverlightApp.BoxAndButton"
Width="250" Height="32">
    <StackPanel x:Name="LayoutRoot" Orientation="Horizontal">
        <TextBox x:Name="TextEntryBox" Width="150" AutomationProperties.Name="Search Query"/>
        <Button x:Name="SubmitButton" Content="Submit"/>

Okay, now that we have the control, let’s use it somewhere.  In fact, it’s a reusable control, so let’s use it twice, just because we can!

<StackPanel x:Name="LayoutRoot">
    <MathPirate:BoxAndButton x:Name="SearchDatabase"/>
    <MathPirate:BoxAndButton x:Name="SearchWeb"/>

(Please note the “MathPirate” namespace that you’ll have to add to your XAML file, if you’re playing the home game.)

Now we run our app and see our two glorious text boxes and buttons.


Now let’s go into UISpy and see what Silverlight or WPF has given us for free.


Now, this is the point in the application development cycle where you’ve made your UI tester cry.  (Or, if they’re anything like me, you’ve made them cry and shoot you with a fully automatic Nerf gun.) While all of the elements are there, everything is jumbled together.  Despite naming one of the controls as “SearchDatabase” and the other as “SearchWeb” and using a hierarchy of controls, SWA has decided that you really want a flat list of useless.  Anyone trying to automate against this isn’t going to know which button is which, and will therefore have to rely on ordinal positions of controls and a whole lot of luck.  If, for some reason, you decide that Web should come first and you go and swap the boxes, you’ll decimate every single test written against this app.  Database queries will go to the Web and Web queries will end up at the Database, and a quantum singularity will form that will destroy the entire universe.  So, let’s fix things, shall we?

I know!  I know!  AutomationProperties!

<StackPanel x:Name="LayoutRoot">
    <MathPirate:BoxAndButton x:Name="SearchDatabase" AutomationProperties.Name="Database"/>
    <MathPirate:BoxAndButton x:Name="SearchWeb" AutomationProperties.Name="Web"/>

Give it a run, and…



So, what gives?  You’re using a nicely hierarchical control tree, you’re giving things nice names and identifiers, why aren’t you getting anything useful from SWA?  The reason:  UIAutomation is primarily designed to expose interactive controls and elements, and your user control isn’t an interactive element in itself, only the text box and button inside it are.  It’s wrapped in a StackPanel, but things like StackPanels, Grids and Canvases in Silverlight and WPF are considered to be strictly for graphical layout and say nothing about the interaction with the system.  As a result, they don’t show up in the control tree. 2  And the BoxAndButton control itself doesn’t show up because you haven’t told SWA that it’s interesting yet.  Let’s do something about that.

The method that WPF and Silverlight use to expose these AutomationProperties is called an “AutomationPeer”.  AutomationPeer is an abstract class that has a bunch of methods for you to implement, like GetNameCore() and GetAutomationIdCore().  The idea is that these Get*Core are supposed to return the value of one of the Automation Properties for UIA to expose.  This gives you a lot of control over what gets seen by UI Automation clients or tools like UISpy.  If you like that level of control, then feel free to inherit directly from AutomationPeer and implement all thirty or so Automation Properties.  The rest of us, who don’t like tedium, will simply use the implementation provided by FrameworkElementAutomationPeer.

Of course, having an AutomationPeer isn’t going to help you much, unless you tell SWA to use it.  You do that by overriding the method OnCreateAutomationPeer() on your control class.  The method is defined on the UIElement base class, so every element in Silverlight already has it, you’ve just probably never noticed it before.  OnCreateAutomationPeer() just needs to return the appropriate AutomationPeer object that exposes your object and the Automation Properties and Control Patterns you want the world to know about.

Okay, that sounded scary and confusing, but it’s not really that bad when you see it in action.  So, let’s get to the code!  Open up the .cs file for your control.

First, add a using:

using System.Windows.Automation.Peers;

Then, override OnCreateAutomationPeer:

protected override AutomationPeer OnCreateAutomationPeer()
    return new FrameworkElementAutomationPeer(this);

And now let’s run our pretty application once more and see what UISpy has for us this time.


Boom-diggity, that’s what I’m talking about.

Now, you have a nice control tree, with your web and database search controls uniquely identified.  While your efforts may not have made the testers completely happy, at the very least, they should have stopped shooting you with the Nerf guns for a while.

But wait!  There’s more!

If you were paying attention, you may have noticed the mention of Control Patterns that I ever-so-slyly snuck in a few paragraphs back.  Control Patterns were the prime focus of the earlier article on using SWA and UIAutomation, but I haven’t really said anything about them here at all.  Why is that?  Because on the implementation side, you typically don’t have to care about them.  You’re using a text box or a button or a scroll bar or whatever that already implements all of the control patterns that it needs, for the most part.  That means you typically don’t have to do a damned thing to get the ValuePattern or InvokePattern to work, while the testers all have to suffer with that idiotic rehash of QueryInterface and COM.

Before you start gloating about that, you need to realize that I’m a tester and now I’m going to make you suffer, too.

All along, we’ve been using a Box and Button as two separate elements.  We’ve put them in a single control, though.  Why not make that single control appear as a single control to UIAutomation?  In other words, why don’t we make our custom control look like it is a text box and a button, rather than something that just contains a text box and button?3

So, somehow, we now have to implement the ValuePattern and the InvokePattern on our BoxAndButton control.  The way to do that, as mentioned before, is through the AutomationPeer.  First, we’ll have to create our own subclass of AutomationPeer.  Again, since I’m not crazy, I’m going to use FrameworkElementAutomationPeer as a base, but you don’t have to.

public class BoxAndButtonAutomationPeer : FrameworkElementAutomationPeer
    public BoxAndButtonAutomationPeer(BoxAndButton owner) : base(owner) { }

Be sure to change your OnCreateAutomationPeer in BoxAndButton to return one of these instead.  If you run this now, you should see everything act exactly the same as it was before you added this new class.

If you go inside the your new AutomationPeer class and type “public override “, you’ll conjure the magic Intellisense window that’ll show you the list of all those Get*Core() and other Automation Property methods I talked about earlier.


You can implement any of them if you want to, but the implementation in FrameworkElementAutomationPeer is usually good enough.  Except for the method GetPattern…

GetPattern is the method that SWA calls on your AutomationPeer when someone using SWA calls “GetCurrentPattern” on an automation element representing your control.  You’ll need to implement it and return an object that implements whatever ControlPatterns you wish to support.  In our case, we want to implement ValueProvider for the Text Box and InvokeProvider for the Button.  The only parameter to GetPattern is a PatternInterface enum containing a value for each of the existing ControlPatterns, so a simple implementation is to switch on patternInterface and return the appropriate object.

public override object GetPattern(PatternInterface patternInterface)
        case PatternInterface.Value:
        return Owner;

        case PatternInterface.Invoke:
        return Owner;

    return base.GetPattern(patternInterface);

If you run it right now and look at it with UISpy, you’ll see that your BoxAndButton control now is apparently supporting the Invoke Pattern and the Value Pattern, just like we want it to do.  Trouble is…  It doesn’t actually support anything.  You may have noticed that I was simply returning “Owner” from GetPattern and found that odd.  Owner is the UIElement we passed into the constructor for FrameworkElementAutomationPeer.  In other words, Owner is the BoxAndButton control itself.  But, we haven’t actually done anything to BoxAndButton to let it know that it’s supposed to support InvokePattern.  Let’s take care of that now.

Each of the control patterns is exposed through an interface. 4  For the Invoke Pattern, it’s IInvokeProvider.  For the Value Pattern, you’ll want to use IValueProvider.  These and other Provider interfaces for for the other patterns live in the System.Windows.Automation.Providers namespace, so be sure to add that.

IInvokePattern is an interface with a single method, called Invoke.  It takes no parameters and returns nothing.  The function is supposed to cause the control to perform some action.  In our case, we’re going to want it to act like the button was clicked.  Like so:

#region IInvokeProvider Members

void IInvokeProvider.Invoke()
    AutomationPeer peer = FrameworkElementAutomationPeer.CreatePeerForElement(SubmitButton);
    IInvokeProvider invokeProvider = (IInvokeProvider)peer.GetPattern(PatternInterface.Invoke);


Okay, that was freaking ugly.  You see, Silverlight and WPF don’t really have a way to easily simulate a button click on the Button class.  So, this method is diving into the world of UIAutomation itself and using the InvokePattern that’s already available on the Button.  Basically, it’s a passthrough.  Making this function suck less is left as an exercise to the reader.

IValueProvider is somewhat more straightforward and sane.  It has three members.  IsReadOnly, a boolean property that returns true/false based on whether or not the control is read only.  Value, a string getter property that returns the value of the control.  And SetValue, a function that takes a string and sets the value of the control with it, because apparently the designers hadn’t heard that properties like “Value” can have both getters AND setters.

#region IValueProvider Members

bool IValueProvider.IsReadOnly
    get { return TextEntryBox.IsReadOnly; }

void IValueProvider.SetValue(string value)
    TextEntryBox.Text = value;

string IValueProvider.Value
    get { return TextEntryBox.Text; }



 Conveniently, all three of those members on IValueProvider map directly to things we can easily do with a text box already.

Now, if you go into UISpy and play around, you’ll see that not only does the BoxAndButton control say that it supports the Value and Invoke patterns, but that you can now actually use them.  You can easily see the Value Pattern in action.  Simply put some text in the box, then look in UISpy, and you’ll see that the custom BoxAndButton now can see the text value.  To see that the InvokePattern is wired up properly, you’ll have to hook up an event handler on the Click event of the button.

Of course, you don’t have to do exactly what I did in my example.  You can use whatever you need and whatever you have available in the I*Provider implementations.  Do it the way that makes sense for you.   You don’t even have to implement these interfaces on the control class directly.  I did it because it was convenient in this case, but it might not make sense for you.  You can use any class you want, it’s entirely up to your design.  Just change what you return from GetPattern.  However, if you put the interfaces on the control class, like I’m doing, I would recommend explicitly implementing these interfaces, since it’s unlikely you’ll want to expose these methods to anyone using the class normally.

There’s just one little annoying thing left about the control.  If you look in UISpy, you’ll see that our BoxAndButton control now supports the Invoke and Value patterns, but we still have the Text Box and Button as children, and those also have the Value and Invoke patterns on them.  They’re not needed anymore.  Let’s axe them, shall we?

If you’ll look at the list of functions available to override on our AutomationPeer, you’ll see one called GetChildrenCore.  You can override that function to tell UIA what your children should be.

protected override List GetChildrenCore()
    return new List<AutomationPeer>();

Obviously, it’s more useful to tell the system that you have children that it wouldn’t ordinarily know about (Like in the case of an owner drawn control), than it is to disown the children that you do have.  So, when using this function in a normal situation, you’re probably going to add something to the list that’s being returned.

Now, if you run the app and look at it in UISpy, you’ll see that the children of the BoxAndButton control have been written out of the will.  You’ll also likely see that, in fact, UISpy is having trouble finding our control.

Element : Element details not available.
Name : TreeValidationException
Message : UI Automation tree navigation is broken. The parent of one of the descendants exist but the descendant is not the child of the parent
Stack Trace : at UISpy.Base.Tree.BuildTree(AutomationElement element)
    at UISpy.Base.Tree.BuildTreeAndRelatedTrees(AutomationElement element)

Well now…  That sucks.  See, what’s happening is that UISpy is finding the real Text Box and real Button controls that still exist and trying to select them, but it’s unable to find their parents in the tree.  In other words, we’ve tampered with the natural order of things and are making UISpy go all loopy.  Good luck with that, I’m gonna end on this high note.

You can find my sample application here (A version that’s not hOrking UISpy):  https://mathpirate.net/log/UploadedFiles/SWASilverlightApp1/SWASilverlightAppTestPage.html

You can get the source code out of SVN here:  https://mathpirate.net/svn/Projects/SWAExample/SWASilverlightApp/

  1. I haven’t done anything with SWA and Windows Forms or Win32 yet, so I don’t know what that entails, but from a quick glance at the docs, it’s a bit more complicated. []
  2. And honestly, you don’t want them to.  It would be insane to try to navigate through all the different panels that appear everywhere.  One of the Silverlight 2 Betas had all of the panels and things exposed and it was frightening. []
  3. Why don’t we?  Because it’s actually useless to do so.  A text box and a button are perfetly good controls to contain.  However, treat this as an exercise in exposing a completely custom owner drawn control to System.Windows.Automation. []
  4. If you’ll remember from the previous article, a large serving of wrath was thrown toward the designers of SWA for not using interfaces so finding out that they do, in fact, use interfaces on objects internally was a bit of a relief, but also upsetting.  I still can’t understand why the person responsible for the design on this side didn’t smack the designers of the consuming side around until they used interfaces, too.  And if it’s the same designer, then they need to smack themselves around until they make up their mind. []

October 10, 2009   No Comments

How can I explain when there are few words I can choose?

Note to self:
According to site statistics, use of Erasure lyrics appears to be more successful in attracting traffic to site than use of titles related to content. Traffic is not actually looking for information on video games, software testing, or testing software for video game playing robots, but traffic is traffic. When I unleash my evil scheme to monetize… CHA-CHING!

It Doesn't Have To Be Like That

October 10, 2009   No Comments

Electric Curiosities: The Value of Plastic

Last week, I wrote about the Aladdin Deck Enhancer.  I was prompted to write about it because I had recently acquired one from a popular on-line auction site that is a primary enabler of my addiction.  It was the complete set, the main unit and all six games that were released.  On top of that, it was sealed.  In a stroke of luck, I paid $70 for the lot.  However, since it was a complete set, in very good condition and sealed, it was probably worth about $200-300.  In fact, just the bare unit and all seven loose cartridges would potentially be worth $70 all by itself.

In video game collecting, as in many other types of collecting, the sealed package demands a premium.  For instance, a complete copy of Super Metroid can run you $40-50, but if it’s still factory sealed, you’re looking at a minimum of $400.  A used copy of Sgt. Pepper on Vinyl might sell for $10, but with an unbroken covering of the original plastic, you might have to talk to Christie’s Auction House.

Thing is, I don’t see the point.

Well, there goes the resale value...

Well, there goes the resale value...

With a quick little slice, I “lost” at least $150 on that Aladdin Deck Enhancer, and it doesn’t really bother me.1  In all honesty, what good is a bunch of games to me if I can’t play them?  If it’s sealed, it might as well be a pretty box with rocks inside.  While I like the container, it’s what’s contained that I really care about.  I have to wonder how many other collectors out there feel the same way.

Now, don’t get me wrong, I’m not about to do something insane like break the seal on a copy of Chrono Trigger.  Instead, I just avoid buying anything that’s still wrapped in unbroken plastic, unless the price is such that I won’t lose any sleep over it.  It’s no great loss to the Video Game World that an Aladdin Deck Enhancer has been unwrapped.  It’s probably still worth more than I paid, even with the plastic opened.

  1. Although, I did consider trying to find someone who had an opened copy and would be willing to trade for a sealed copy.  After all, it might not be worth anything to be, but I know that someone out there might want it. []

October 7, 2009   No Comments

Electric Curosities: Enhance your NES!

Back in the early 90’s, toward the end of the life of the NES, the company who was responsible for the Game Genie came up with another idea to make Nintendo angry. It was called the Aladdin Deck Enhancer. Reportedly designed to allow “enhanced” games on the NES by providing extra RAM and better graphics, it was called “the future of console game play” by its very own box. In reality, however, it was an ill-timed plot to sell cheap, unlicensed games for the NES.

Cartridges for the NES were fairly expensive to produce.  It wasn’t just the ROM chip, a simple circuit board, and a big plastic shell, like there was in the days of the Atari.  Sometimes NES games needed some extra memory, sometimes they needed a graphics coprocessor, but they always, every single one of them, needed the additional electronics to satisfy the 10NES lockout chip.

You see, Nintendo learned a lesson from the Great Crash of 83.  Atari didn’t have any kind of lockout device on the Atari 2600.  This allowed third party developers like Activision and Imagic to produce some of the best titles of the system without needing the permission of nor needing to pay Atari.  It also allowed anyone with a ROM burner to produce mountains and mountains of unashamed garbage that masqueraded as video games.  You think ET caused the Crash?  No.  Custer’s Revenge caused the Crash.  Star Fox caused the Crash. 1   Nintendo wasn’t going to let their system be killed by crappy games.  The solution to this problem came in the form of the 10NES lockout.

By setting up a two-part lock electronic lock, they prevented a critical mass of lousy games from accumulating and thereby averted a full scale market implosion.2  One part was in the console.  When you put in a cartridge and turned the power on, a challenge was sent to the cartridge.  If the cartridge responded properly, then you got to play the game.  If the cartridge failed to respond correctly, you got a blinking power light and a flashing gray screen of death.  And the only place to get the chip that acted like the key to the lock was Nintendo.  They patented and copyrighted the design, so they’d sue you no matter what you tried to do to circumvent the lockout.  But, Nintendo also recognized that the key to a successful console was third party support.  Game publishers were welcome to make games for the NES, as long as they abided by all sorts of requirements and rules (Including censorship), and, on top of that, pay for the privilege of getting the chip for the cartridge and the “Nintendo Seal of Quality” on the box.

The program was successful.  Because of it, Nintendo avoided a flood of terrible and worthless games.  Sure, there were games that sucked, but for the most part, anything that had the Nintendo Seal of Quality was at least half-way decent.  Even crap-buckets like Total Recall or Super Pitfall were miles above the uninspired and derivative silicon wastelands that plagued the Atari 2600 in 1983.   The lockout chip also made piracy of NES carts more difficult.  Without the 10NES key chip, a game wouldn’t play, and Nintendo wasn’t about to hand out those chips to pirates.

Of course, the flip side should be obvious.  Because Nintendo controlled the chip that was the key to the system, Nintendo controlled every game that was allowed to play on it.  Want to put out a game with blood in it?  Nope.  Want a game with strong religious themes or symbols?  Ain’t gonna happen.  Adult content or mature themes?  Uh-uh.  Want to release the same game for the NES and for Sega?  Not for another couple of years.  Want to put out more than a handful of games a year?  Fat chance.

Don’t want to pay the licensing fee to Nintendo…?

Whenever there is a technology that will prevent someone from making money, that someone will find a way to defeat that technology, thereby allowing money to be made.  That is exactly what happened with the 10NES lockout chip.  Some people created pass-through carts, which looked like a Game Genie and required you to plug in a licensed NES cartridge in order to play.  It then used the real 10NES chip in the licensed cartridge to unlock the NES, which then loaded the unlicensed game in the passthrough.  Other companies thought that was too tacky looking and instead decided to simply fry the 10NES chip in the NES system by sending it a voltage spike.  However, the truly dedicated ones reverse engineered the 10NES chip from the specifications in documents obtained under false pretenses from the US Patent Office.  The corporation who was responsible for this awesome act of technological trickery?  Atari.  The Atari who had been nearly destroyed by unlicensed games had decided to create its own unlicensed NES games under the Tengen brand, largely to get around Nintendo’s licensing fees and severe non-compete restrictions.3

Unlicensed NES Cartridges

Unlicensed NES Cartridges: Bible Adventures (Wisdom Tree), Quattro Adventure (Camerica), Fantasy Zone (Tengen)

Most manufacturers of unlicensed NES games ended up following in Atari/Tengen’s shoes and created 10NES knock-off chips.  However, those chips raised the cost of producing a cartridge and cut into the profit margin.  Which brings us back to the Aladdin Deck Enhancer that I was talking about before I went off on that long-winded tangent of a history lesson.  You see, there was nothing about the Aladdin Deck Enhancer that was really an enhancement at all.  It actually wasn’t about the extra memory, it actually wasn’t about the graphics coprocessor.  It was about the knock-off 10NES chip.  The plan behind the Aladdin Deck Enhancer was that they’d sell the base cartridge, which contained the lockout chip and some other chips, then sell the games that plugged into the base separately.  As many games as you wanted, but only one lockout chip.  The games, since they wouldn’t need to include the extra electronics, would be cheaper to produce and therefore cheaper to sell.  On top of that, why not license other games for use with the Aladdin Deck Enhancer?  Certainly there are other companies or game developers itching to get their games on the NES without having to deal with the Iron Fist of the Big N.  It’s like a license to print money!

Aladdin Deck Enhancer

Or rather, in 1988, it would have been a license to print money.  But the Aladdin Deck Enhancer came out in 1993, firmly in the period of 16-bit domination.  If people wanted enhanced graphics and bigger games, they didn’t buy games on some convoluted half cartridge that required some bizarre mutant shell for them to work.  No, they went out and bought a Super Nintendo.  The company which distributed the Aladdin Deck Enhancer was ruined and folded a few months later.

Aladdin Deck Enhancer

The game “Dizzy The Adventurer” was included as a pack-in cartridge.  The other six cartridges released were The Fantastic Adventures of Dizzy, Quattro Adventure (including Boomerang Kid, Super Robin Hood, Linus Spacehead, and Treasure Island Dizzy4 ), Big Nose Freaks Out, Micro Machines, Quattro Sports (including Baseball Pros, Soccer Simulator, Pro Tennis, and BMX Simulator), and Linus Spacehead’s Cosmic Crusade. 5  11 other games were promised on the box, and while none of those were released as Deck Enhancer carts, most were later (or had already been) released as standalone unlicensed NES carts.  While not crowning pinnacles of gaming glory, the Aladdin games aren’t complete abuses of the physical properties of silicon.   It’s likely that some of the games would have easily been qualified for the “Nintendo Seal of Approval”, had they wished to go legit.6

  1. Not THE Star Fox, although, interestingly enough, Star Fox for the Atari 2600 is the reason THE Star Fox had to be called “Starwing” and “Lylat Wars” in Europe. []
  2. Atari learned the same lesson.  In its 7800 ProSystem console, there’s a lockout mechanism that’s so strong that it is actually against the law to export an Atari 7800 due to restrictions governing military grade cryptography.  In Atari’s case, however, a second full scale market implosion was avoided, not by the lockout chip, but rather by not actually having a market that could implode. []
  3. And, of course, they got sued…  Although some may claim that the lawsuit was less about protecting their technology than protecting their reputation, as the lawsuit focused on the Tengen version of Tetris, generally considered superior to the Nintendo version. (Much the same way that Atari had sued Magnavox for the superior K.C. Munchkin infringing on the less-than-stellar 2600 Pac-Man…) []
  4. It’s obvious that Codemasters felt that Dizzy would be their killer app, with three Dizzy games available for the unit and another one promised on the box.  Although apparently big in the UK, sadly, the failure of unit meant that Prince Dizzy of the Yolk Folk would remain obscure in the US… []
  5. If you’re ever in need of a Commodore 64 flashback, you should give Dizzy or the games on Quattro Adventure a spin.  Not that you ever actually played those games on a C64, but they’ll certainly remind you of one. []
  6. And if they hadn’t been made by the same people who made the Game Genie… []

October 3, 2009   2 Comments