Cannot find overload for MgMappingService::GeneratePlot()

[waltweltonlair]

Run the MapGuide 1.0 sample application. Select the Plot as DWF task from the task list. Select a scale for the plot, and click Plot. This does not generate any output, but creates a PHP error in the Apache log: PHP Fatal error: Arguments passed did not match any overload for method _wrap_MgMappingService_GeneratePlot in C:\Program Files\Autodesk\!MapGuideEnterprise2008\WebServerExtensions\www\phpviewersample\plot.php on line 72.

Plotting the current map view, without specifying a scale, works.

Note: a similar problem occurs with the constructor for MgMapPlot(MgMap *map, MgCoordinate *center, double scale, MgPlotSpecification *plotSpec, MgLayout *layout).

PHP error in Apache log is: PHP Fatal error: Arguments passed did not match any overload for method _wrap_new_MgMapPlot in C:\Program Files\Autodesk\!MapGuideEnterprise2008\WebServerExtensions\www\samplesphp\custom_output\multiplot.php on line 70.

[waltweltonlair]

The GeneratePlot call for which the problem occurs takes, as its second argument, an MgCoordinate object. MgCoordinate is a base class from which other classes like MgCoordinateXY or MgCoordinateXYM derive. In this case we're passing in an MgCoordinateXY object.

Because GeneratePlot has multiple overloads, the SWIG generated PHP code needs to check the class type of this parameter to determine which overload to call. It's doing this by comparing the class type name of the passed-in object to the class type name declared in the overload. In our case the class type name for the pass-in object is "MgCoordinateXY", and the class type name declared in the overload is "MgCoordinate". The comparison is a string equality check, and therefore it fails. So SWIG ends up failing to correctly identify that the passed-in parameters match one of the GeneratePlot overloads.

Somehow the autogenerated SWIG code needs to be made smarter - it needs to take into account object inheritance when it does the checks. Maybe this is a supported feature of SWIG, and we need to figure out how to turn it on. It could also be a limitation of SWIG, and that would be bad, since I bet there are many methods in our API for which a similar problem would arise.

Note that the information to do the correct checks is there. SWIG obtains a ClsInfo object for the parameter, and this includes its inheritance structure. So it's possible to check the function type not only against the parameter's most derived type (like it currently does), but also against its parent types. It could simply start at the most derived type and keep checking until it finds a match or runs out of parent types (in which case the parameter type doesn't match the function type).

[anonymous]

Duplicate of ticket #141.