An API to Control MapPoint 2006 GPS Features - Part I of II
Paul Larson shares an API he developed to add programmatic GPS functionality to MapPoint code projects and includes a demo to illustrate how the API works.
With the release of MapPoint 2006 North America (MP2K6NA) earlier this year, many users have been elated with the new map content and the addition of GPS features and Driving Guidance to the product. Likewise, many developers have thus found issue with the lack of improvement to the MapPoint API, specifically in relation to these new features. Being of the latter group, I decided to roll-my-own API to add programmatic GPS functionality to my MapPoint code projects.
Part I of this project will simply encapsulate the standard UI for GPS tracking, centering, rotation, Driving Guidance and GPS-trailing functionality, along with some UI state detection.
Part II of the project will deal with extending the base GPS API by implementing a class to capture the GPS Sensor information. I will also extend the API to handle usage of the ActiveX control version of MP2K6NA.
Using a couple old windows API tricks for cross-process state detection and base window-messaging (out-of-process), it is quite possible to extend an API to control the new GPS features programmatically in MapPoint 2006.
In a standard installation of MP2K6NA, the GPS functionality of the UI is disabled (grayed-out) when a map or template is opened using the MapPoint API. However, according to the product documentation, all pane-states of the application are saved as part of the map or template file. Since the GPS Panel is indeed a pane with state, saving a template with this pane open (and having had the GPS com port configured) does indeed enable GPS functionality when re-opening the file using the API. I have included a base template file with this setting as part of the project, choosing to name it “GPS_ON.ptt.” Furthermore, I have noted that if a map or template is loaded programmatically after the initial load of GPS_ON.ptt, the GPS functionality of the UI remains available.
Hence, to provide our API it is only a matter of encapsulating UI state and sending low-level messages to the UI. Worthy of additional note is that by using the Windows API messaging methodology, we can interact with non-visible controls, which improves user experience and occasionally avoids certain process-blocking issues.
The project was developed using Visual Studio 2003, VB.Net and the .NET Framework version 1.1.4322. For the most part, the project should also load and compile fine in Visual Studio 2005 and the .NET Framework version 2.0.50727 as well. Additionally, I found it rather helpful to use Spy++ to enumerate the MapPoint window structures while working on the code, and the Visual Studio 6.0 API Viewer to delve into and convert the user32.dll WinAPI functions.
Other than finding and storing the proper handles to the controls in the MapPoint application, the only other trick is to send BM_CLICK messages to these windows so as to simulate the user having interacted with the controls. We also use the API method GetWindowInfo() to return visibility and state information about certain controls.
The entire code for the class is included here: mpGPS_API.zip
Finally, being that the API is written as a DLL class module for use in your own MapPoint programming projects, I have included a windows forms-based demo application showing the usage of the API. You can download the demo here: mpGPS_Demo.zip
Click here to join in the discussion of this article on MapForums.com.