topic Redefining S_OK, S_FALSE, SUCCEEDED, and FAILED is not very friendly in File Geodatabase API Questions

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

MartinDaly — Thu, 19 May 2011 14:19:10 GMT

Could more FileGDB API-specific names be used instead?

Martin

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

DavidSousa — Thu, 19 May 2011 15:35:19 GMT

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

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

MartinDaly — Fri, 20 May 2011 08:13:32 GMT

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

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

VinceAngelo — Tue, 24 May 2011 20:33:39 GMT

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

- V

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

__11 — Sat, 11 Dec 2021 22:37:55 GMT

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.