Redefining S_OK, S_FALSE, SUCCEEDED, and FAILED is not very friendly

[MartinDaly]

Could more FileGDB API-specific names be used instead?

Martin

[DavidSousa]

Could more FileGDB API-specific names be used instead?

Martin

I am not sure that I understand the concern.  Can you elaborate on why you think this is a problem, and what you would propose instead?

The way these things have been redefined appears to be totally harmless.  The definitions are 100% consistent and functionally equivalent with the normal definitions in Windows.  It was necessary to do this in order to remove Windows dependencies.

-David

[MartinDaly]

I am not sure that I understand the concern.  Can you elaborate on why you think this is a problem, and what you would propose instead?

The way these things have been redefined appears to be totally harmless.  The definitions are 100% consistent and functionally equivalent with the normal definitions in Windows.  It was necessary to do this in order to remove Windows dependencies.

-David

If they are "100% consistent and functionally" equivalent then why bother #undef-ing them first? If they are not there and you want them then check for their existence and only #define them if necessary. That would be 100% friendlier. Any file that #include-s them has messed up Intellisense that refers to your fgdbError.

Finally, they are 100% unused in the SDK-supplied headers; they are only used in the samples. If SDK client code needs them, then SDK client code should be responsible for ensuring their existence.

Martin

[VinceAngelo]

Have you tried using the Beta-3 release?  These macros are all defined appropriately in FileGDBCore.h
(which is included by FileGDBAPI.h).

- V

[__11]

The existing definition (in API 1.3) is a problem, when building with Visual Studio 2010, because if I include winerror.h after FileGDBAP.h I get a macro redefinition warning. In general, I should not have to worry about what order I include the headers. This is especially so when there are multiple headers. My code is not at simple as

#include <winerror.h>
#include "FileGDBAPI.h"

It's actually:

// in main.cpp ...
    #include "FileGDBAPI.h"
    #include "AddFile.h"

// in AddFile.h ...
    #include "RunParameters.h"

// in RunParameters.h ...
    #include "Geo.h"

// in Geo.h ...
    #include <atlcomcli.h> // this includes winerror.h, which causes the warning

The solution is to #include AddFile.h before FileGDBAPI.h in main.cpp, but I shouldn't have to search through that many layers of header files (each of which has only the #inclusions it needs) to find the problem.

Regardless of the complexity of my own code and file structure, I should not have to worry about the order of inclusion of your and Microsoft's header files.