MapPoint and GPS: Another Stupid Pill
MapPoint is a Microsoft product that's a lot like Streets & Trips, with additional features. Most interestingly for me, it includes interfaces to programmatically control it, plus an embeddable ActiveX control. Since I was putting a computer into my car, it seemed like just the thing.
In Streets & Trips 2004, and MapPoint 2004, Microsoft added GPS support. You can easily configure it such that the map tracks your current position as reported by the GPS. You can also configure it such that your view of the map is rotated such that your direction of travel is always up. Quite convenient for in-car navigation.
Unfortunately, search as I might, I could find absolutely no mention of the GPS features in the programming interface documentation. "Drat!" says I to myself. "The GPS features probably came in too late for the programming interface people to catch up." I was disappointed, but I understand how these things can happen.
So I decided I would just send Windows messages to the embedded control to convince it that I had manually pressed the UI buttons that enable GPS support. No luck; these menu options aren't in the UI for the embedded control. "No problem," I say, "I'll just start the full application via the scripting interface, and use it." So I code that up, and discover that, when started via the scripting interface, the GPS menu items exist, but are disabled.
There's a property in the scripting interface called PaneState. It returns an enum value saying which side-panel is currently being displayed, with values representing none, route planner, legend, find places and territory manager. I imagine that during the development process, a conversation like the following took place between a developer and a product manager.
Dev: What should we return for the PaneState property when the GPS pane is being displayed? Should I just invent a new value for the enum?
PM: What'll that do to compatibility with existing applications?
Dev: Well, if they don't display the GPS pane, they'll never notice the difference. If they do, they'll get an enum value they've never seen before.
PM: But won't an app break if it gets a value and doesn't know what it means?
Dev: Some app might, but most will tolerate it. Besides, it only happens if a user goes out of his way to show the GPS pane.
PM: I've got it! Let's just make it impossible to show the GPS pane if you're using the scripting interface. Then we won't have an app-compat problem.
So they go forth and implement. Out of a fear of a hypothetical user breaking a hypothetical app by turning on something new, they make the product's single most important new feature completely unusable from every app. This is not a good trade-off, and is deserving of Jimbo's Stupid Pill Of The Day award.
In any event, that was in 2004. What changed in the programming interface for MapPoint 2006? Nothing. Nada. Zilch. How about the recently-released MapPoint 2009? You guessed it: nothing. So, five long years after introduction of the GPS features, you still can't script them. (I know, life sucks.) But the worst of it is that five years later, you still can't use the GPS features at all, in any way whatsoever, if you're using scripting for any purpose.
Actually, the above paragraph isn't quite true: While you can't use the GPS features at all if you start MapPoint by creating an instance of the MapPoint.Application object, if you start MapPoint using CreateProcess and then, once it's initialized, connect to it using the GetActiveObject API, the GPS features remain enabled. You'll still need to send window messages to simulate button presses, but at least it's possible. Unfortunately, when the MapPoint team hears about this, they'll probably deem it a bug and disable it in MapPoint 2011. (Hint: If you do this, people will wait in line to give you wedgies.)