I have spent the last three weeks of my life, more or less, trying to do what should be a trivial task: get a map out of Microsoft MapPoint 2004 (the desktop app, not the Web service) and save it as an independent image. There are all sorts of problems with this though!
It seems that someone at Microsoft decided to cripple the MapPoint ActiveX control, for reasons beyond my understanding. Functionality that exists within the MapPoint software, and is accessible via VBA just cannot be used from outside of VBA, such as saving the map as an HTML file. The solution suggested? Fire up an entire instance of MapPoint and programmatically command it to do a "Save As". For whatever reason, what is a 1 second operation through the MapPoint application becomes a 2 20 minute (you read that right, 20 minutes for some maps!) operation when run from VB.Net. During this period of time, MapPoint like to glom 100MB of RAM and 100% CPU.
Every single method that I have seen suggested simply does not work. Even telling it to copy to the clipboard fails after about 1300 iterations (I am looping through a large number of maps). The only thing anyone can tell me about this error is to keep retrying it within a loop and eventually it will work. Code that fails at random is not code I think I want to be using.
What bothers me about this is Microsoft's decision behind this. I just cannot fathom why they only included basic functionality to the ActiveX control, especially when that functionality exists within MapPoint itself. Since I need to have MapPoint installed to use the ActiveX control, it is not like they would be losing sales or anything like that by providing full functionality to the ActiveX control. This reminds me a lot of the undocumented Windows APIs that Microsoft used to keep other companies from writing software as capable as their own software. If it were not for the fact that MapPoint costs a fraction of what my other options are, I would be more than happy to dump it.
This is actually my first time using an ActiveX control of an Office product. Up until now, all of my Office programming has been with VBA within the application itself. Has anyone else had these kinds of problems? If so, I may need to reconsider a few things in how I was hoping to do some future projects.
Justin James is the Lead Architect for Conigent.