skutz

How to resolve the 10.1 compile errors due to esriGeometry::LONG_PTR in esriCarto.tlh

Discussion created by skutz on Jan 23, 2012
Latest reply on Jan 24, 2012 by skutz
Our product uses ArcGIS Engine Runtime with the MapControl and PageLayoutControl and is written in Visual C++ (MFC), Visual Studio 2010.
References to the ArcObjects libraries are obtained via the normal mechanism of using the #import statement.

Trying to build/compile in ArcGIS 10.1 Beta 2 yields the following fatal error (repeated so many times that compile just stops):
---------------------------------
C:\ProductDevSource\StCommon\Include\StPageLayoutMapViewData.h(146): error C2872: 'LONG_PTR' : ambiguous symbol
1>          could be 'C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\basetsd.h(138) : __w64 long LONG_PTR'
1>          or       'c:\productdev\synergee\gas\unicode\debug\stnetwork\esrigeometry.tlh(719) : esriGeometry::LONG_PTR'
---------------------------------

  Investigating, it turns out that esriGeometry, starting in ArcGIS 10.1, has chosen to inlcude its own TypeDef for the LONG_PTR data type. It appears that the definition is a duplicate of what Microsoft has already defined in its own header file basetsd.h.

  However, since esriGeometry is now defining it, the compile process reports the ambiguous condition as the error shown ablve.

  We tried just including an "exclude" clause on the #import for esriGeometry to avoid using the ArcGIS definition (and let all code use the Microsoft definition) as follows:
#import "esriGeometry.olb" raw_interfaces_only raw_native_types named_guids exclude("LONG_PTR")

However, that triggered the next error from the esriCarto libary:
1>c:\productdev\synergee\gas\unicode\debug\stnetwork\esricarto.tlh(36907): error C2039: 'LONG_PTR' : is not a member of 'esriGeometry'

It turns out this error occurs because esriCarto is now explicitly referencing the esriGeometry::LONG_PTR data type in the following method definition:
virtual HRESULT __stdcall OnMessage (
        /*[in]*/ unsigned long msg,
        /*[in]*/ UINT_PTR wParam,
        /*[in]*/ esriGeometry::LONG_PTR lParam ) = 0;


  We already have many, many references to the Microsoft LONG_PTR data type throughout our code base, so it is not practical to make all of those references somehow point to the ArcGIS definition in esriGeometry::LONG_PTR.

   We are continuing to experiment with various approaches of modifying the #import statement options for esriGeometry and esriCarto, but so far have not found any way to resolve the problem. 

  We would appreciate any thoughts other developers may have on how to get past this.

  Thanks for your insights.

Scott

Outcomes