Richard,
Yes, it seems we also end up struggling with resolving a new set of #import problems with each new major ArcGIS release.
The thing that is so frustrating on this particular item is why ArcGIS felt it needed to create its own typedef for LONG_PTR instead of just using the existing typedef provided by Microsoft in the basetsd.h header file.
- It seems that this has to cause conflicts with any existing code that is already using the Microsoft LONG_PTR typedef
- If ArcGIS really does need a custom version, then it would seem prudent for ArcGIS to choose a name different from the Microsoft name.
- We are wasting a lot of time trying to find some way to workaround this problem, when it seems ArcGIS could have avoided the problem by just using a name that is not guaranteed to conflict with the existing Microsoft typedef.
Historically, we have been able to resolve the #import issues by using combinations of "exclude" or "rename" attributes on the #import statement. Sometimes we had to modify our source code files that interact with ArcObjects to specify new names assigned via the "rename" attribute.
The significant thing to resolving those earlier problems was that the code that had to be adjusted was in our product source files (so we could get to it and modify it).
The problem we have encountered now with esriGeometry::LONG_PTR is that ArcGIS itself is specifying the typedef in its esriGeometry library and then explicitly referring to that typedef in the ArcGIS esriCarto library. So we cannot get to the code that is using this new typedef to modify it.
We have been experimenting with various combinations of the "rename" attribute on our #import statement and have been able to get close, but still no success.
When esriGeometry is imported with the following #import statement:
#import "esriGeometry.olb" raw_interfaces_only raw_native_types named_guids
the resulting series of statements in the resulting esrigeometry.tlh file are as shown below. This is what you would expect: the typedef is defined and then it is used in subsequent statements.
--------------------------------------------------
#if !defined(_WIN64)
typedef __w64 long LONG_PTR;
#else
typedef __int64 LONG_PTR;
#endif
typedef LONG_PTR esriSpatialReferenceImplHandle;
typedef LONG_PTR esriPrecisionImplHandle;
typedef LONG_PTR esriPrecisionExImplHandle;
typedef LONG_PTR esriProjectionImplHandle;
typedef LONG_PTR esriGeoTransformationImplHandle;
typedef struct _esriSegmentInfo esriSegmentInfo;
typedef LONG_PTR TopologyHandle;
typedef struct _WKSPointVA WKSPointVA;
--------------------------------------------------
But this appaorach then also generates the fatal "ambiguous symbol" error shown in the original posting in this thread.
We tried adding the following "rename" attribute to the #import statements for esriGeometry and esriCarto:
#import "esriGeometry.olb" raw_interfaces_only raw_native_types named_guids rename("LONG_PTR", "esriLONG_PTR")
#import "esriCarto.olb" raw_interfaces_only raw_native_types no_namespace named_guids exclude("OLE_COLOR", "OLE_HANDLE", "VARTYPE", "UINT_PTR"), rename ("ITableDefinition", "IEsriTableDefinition"), rename ("IRow", "IEsriRow") rename("LONG_PTR", "esriLONG_PTR")
The good news is that seemed to bypass the original problem we saw in the resulting esriCarto.tlh file by generating the following output for esriCarto:
virtual HRESULT __stdcall OnMessage (
/*[in]*/ unsigned long msg,
/*[in]*/ UINT_PTR wParam,
/*[in]*/ esriGeometry::esriLONG_PTR lParam ) = 0; <-- good: The reference into esriGeometry was adjusted to esriLONG_PTR
However, the fatal error moved back to esriGeometry.tlh because the content of the *.tlh file generated via #import with the "rename" attribute has the effect of moving the first use of the typedef to be *before* the typedef itself is actually specified, as shown below:
--------------------------------------------------
typedef esriLONG_PTR esriSpatialReferenceImplHandle; <-- this out-of-sequence statement position causes the problem
#if !defined(_WIN64)
typedef __w64 long esriLONG_PTR;
#else
typedef __int64 esriLONG_PTR;
#endif
typedef esriLONG_PTR esriPrecisionImplHandle;
typedef esriLONG_PTR esriPrecisionExImplHandle;
typedef esriLONG_PTR esriProjectionImplHandle;
typedef esriLONG_PTR esriGeoTransformationImplHandle;
typedef struct _esriSegmentInfo esriSegmentInfo;
typedef esriLONG_PTR TopologyHandle;
typedef struct _WKSPointVA WKSPointVA;
--------------------------------------------------
and this results in the following compile errors:
1>c:\productdev\synergee\gas\unicode\debug\stnetwork\esrigeometry.tlh(718): error C2146: syntax error : missing ';' before identifier 'esriSpatialReferenceImplHandle'
1>c:\productdev\synergee\gas\unicode\debug\stnetwork\esrigeometry.tlh(718): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\productdev\synergee\gas\unicode\debug\stnetwork\esrigeometry.tlh(718): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>c:\productdev\synergee\gas\unicode\debug\stnetwork\esrigeometry.tlh(720): error C2371: 'esriGeometry::esriLONG_PTR' : redefinition; different basic types
1> c:\productdev\synergee\gas\unicode\debug\stnetwork\esrigeometry.tlh(718) : see declaration of 'esriGeometry::esriLONG_PTR'
1>c:\productdev\synergee\gas\unicode\debug\stnetwork\esrigeometry.tlh(1097): error C2061: syntax error : identifier 'esriSpatialReferenceImplHandle'
1>c:\productdev\synergee\gas\unicode\debug\stnetwork\esrigeometry.tlh(2053): error C2061: syntax error : identifier 'esriSpatialReferenceImplHandle'
So we will have to continue the investigation.
But until this problem can be resolved, we find outselves in the position where it is not possible to physically build our product in the ArcGIS 10.1 (Beta 2) environment.
Thanks again for your insights.
Scott