View Full Version : Cancel in ExportGPX method

08-20-2011, 11:41 PM
I just upgraded from MP 2009 to 2011 to gain access to the ExportGPX functionality. It all works fine when done manually through Data -> Export to GPX in MapPoint. I can even invoke the ExportGPX method of the application object from within my VBA application.

However (and this could be a VBA question rather than a MapPoint question), if I invoke the ExportGPX method from VBA, and the user then clicks Cancel in the export dialog in MapPoint, it generates a "catastrophic failure" error in my application.

I know I could just trap for this error; however, I am a little hesitant to assume that this Cancel is the only reason the error could occur and very curious as to why that method generates an error when the user clicks Cancel. Isn't Cancel a perfectly normal response in some cases, not an error condition?

For now, I just have the users doing the export manually from within MapPoint; however, this is somewhat important in that I plan to eventually provide the user with the ability to pre-specify the export filename & path to save time browsing during the export process.

08-25-2011, 07:43 AM
I experienced this same error with vb.net and MP 2010 ... the only way I could stop it was to trap the entire ExportGPX control ... something I didn't really like to do ...

The cancel button created a critical error in XP and Vista and a non-critical error in Windows 7 ...

08-25-2011, 08:29 AM
Brian: Do you have some code?

Assuming there's nothing obviously wrong, then xjack's approach is probably the best.

08-25-2011, 02:11 PM
The code is too simple: appMapPoint.ExportGPX

appMapPoint is the MapPoint application object, and I invoke the ExportGPX method after I have programmatically populated the map with pushpins, routed & optimized stops, etc.

Here is more information than anyone will want to read, but it may help the next poor soul facing this issue:

I think it is a bit odd that two MS products (MapPoint & VBA) cannot communicate more specifically than "Catastrophic failure". I would hardly categorize Cancel as catastrophic, and I assume "catastrophic failure" could mean many other things besides "The user clicked Cancel", so I have already trapped and ignored the error #-2147418113 only with some misgivings regarding the inference that this is the only reason it could occur at this point in my application. (The 0.00001% chance that the same error could occur for some other reason at exactly the same point is more risk than I like to take as a developer...)

The ExportGPX method (along with many others) may be too new for MS to have included situation-specific error codes, since several older methods do have situation-specific error codes, such as these:

Attempts to optimize a route containing an impossible route (such as two points on opposite sides of an ocean), actually provides an "Unable to optimize error".
Error # -2147217383 is returned when an address cannot be found.
Error # 429 occurs if MapPoint is not installed.
Errors #462, -2147417848, -2147155969 all occur when some reference is made to the MapPoint application object, its collections, methods, events, or properties after the user has closed the map, in which case the object reference in VBA still exists even though the target application has been closed or is in the process of being closed.
For the next soul that encounters this issue, here is my entire procedure, replete with the error trap:

Private Sub ButtonExportGPS_Click()
On Error GoTo ErrorHandler
'exit if no map open
If appMapPoint Is Nothing Then 'appMapPoint is the MapPoint application object
MsgBox "Please open a map first.", vbExclamation, ""
ButtonMapSend.SetFocus 'the button that opens MapPoint & populates it with data
Exit Sub
End If
appMapPoint.ExportGPX 'export current map contents to GPX file
Exit Sub
ProcedureCurrent = "ButtonExportGPS_Click"
Select Case Err.Number
Case -2147418113 'this error occurs if user clicks Cancel in GPX export in MapPoint; trapping here effectively ignores it
StatusReset 'resets status bar
Case Else
Call ErrorHandlerControl(Me.Name, ProcedureCurrent) 'public proc that identifies the context & nature of the error for the user
End Select
End Sub

FYI: Although it might be recommended to include the MapPoint library reference in VBA, I cannot do so because, on computers not having MapPoint installed, this causes errors in seemingly non-MapPoint-related portions of my application.