At least one of the arguments for cannot be marshaled by the runtime marshaler


When using the MapWinGIS control on a WinForms application that application produces the following compile warning for several MapWinGIS classes:

warning MSB3305: Processing COM reference "MapWinGIS" from path "\src\bin\Win32\MapWinGIS.ocx". At least one of the arguments for '***' cannot be marshaled by the runtime marshaler. Such arguments will therefore be passed as a pointer and may require unsafe code to manipulate.

These are the reported classes:

  • IShapeDrawingOptions.DrawShape

  • IShapeDrawingOptions.DrawRectangle

  • IShapeDrawingOptions.DrawPoint

  • IShapeDrawingOptions.DrawLine

  • ILinePattern.Draw

  • ILineSegment.Draw

  • _DMap.DrawBackBuffer

  • ICharts.DrawChart

  • Map.DrawBackBuffer

  • ShapeDrawingOptions.DrawShape

  • ShapeDrawingOptions.DrawRectangle

  • ShapeDrawingOptions.DrawPoint

  • ShapeDrawingOptions.DrawLine

  • Charts.DrawChart

  • LinePattern.Draw

  • LineSegment.Draw



Paul Meems
September 15, 2019, 1:25 PM

I’ve made the changes. Still need to make unit test to verify

Jerry Faust
August 2, 2019, 4:41 PM

No, I'm sorry, I have not made the changes yet. So I guess if you have opportunity, go ahead.


Paul Meems
August 2, 2019, 9:10 AM

Any progress on this? I can make the changes as well if you don’t have the time for it.

Jerry Faust
July 16, 2019, 4:15 AM

It would appear that Windows HANDLEs can be shared between 32 and 64 bit applications, and that a handle will always fit into a 32 bit variable. See the following:

Interprocess Communication Between 32-bit and 64-bit Applications

And interestingly, it appears that the int type in MIDL is interpreted as a 32 bit integer, even though in c/c++, it adapts to the platform.

int attribute

Considering these things, and considering that the existing int definition has worked in both 32 and 64 bit builds of the OCX, I think it best to go with the int type, as used in the ‘VB’ versions of the calls, removing the superfluous int** type, which has always been interpreted in the code as an int type rather than a pointer type.

As such, and in agreement with your suggestion () I will submit a change to the standard Draw methods, submitting the HDC as an simple int type (as is done in the ‘VB’ versions of the calls) and remove the ‘VB’ calls altogether.

Paul Meems
July 15, 2019, 8:57 AM

I got some comments on my StackOverflow question. One is interesting:

try to replace int** by INT_PTR and tlbimp (with help from the midl compiler) should see it as a .NET Int64 (so both 32 and 64 pointer sizes will fit int), but it's still not an Automation-compatible interface

Not sure if INT_PTR in this case is better than int.

What do you think?

Regarding your question about what to keep. I think we should change the ‘standard’ version and remove the VB version.



Jerry Faust


Paul Meems



Epic Link

Affects versions


Fix versions