FDK: #define FAPI_*_BEHAVIOR

[Zdenek100]

FDK allows for defining the following symbols: FAPI_4_BEHAVIOR, FAPI_5_BEHAVIOR, FAPI_55_BEHAVIOR and FAPI_6_BEHAVIOR. What FAPI_*_BEHAVIOR shall be defined for FDK12? I found the follwoing inconsistency:

FIRST:

********

fapi.h defines F_ApiNotify() as follows:

#ifdef FAPI_4_BEHAVIOR

extern VoidT F_ApiNotify FARGS((IntT notification, F_ObjHandleT docId, StringT filename));

#else

extern VoidT F_ApiNotify FARGS((IntT notification, F_ObjHandleT docId, StringT sparm, IntT iparm));

#endif

If I look at F_ApiNotify() in FDK 12 Programmer's Reference, I derive that FAPI_4_BEHAVIOR shall NOT be defined.

SECOND:

*************

fapi.h defines F_AttributeDefT as follows:

typedef struct {

          StringT name;

          BoolT required;

#ifdef FAPI_5_BEHAVIOR

          BoolT readOnly;

#else

          UIntT flags;

#endif

          IntT attrType;

          F_StringsT choices;

          F_StringsT defValues;

          StringT rangeMin;

          StringT rangeMax;

} F_AttributeDefT;

Comparing it with FDK 12 Programmer's Reference, I conclude that FAPI_5_BEHAVIOR shall NOT be defined.

THIRD:

*********

fchannel.h defines F_ChannelOpen() as follows:

#if defined(FAPI_5_BEHAVIOR) || defined(FAPI_4_BEHAVIOR)

extern ChannelT F_ChannelOpen FARGS((FilePathT *path, StringT type));

#else

extern ChannelT F_ChannelOpen FARGS((FilePathT *path, CStringT type));

#endif

Comparing it with FDK 12 Programmer's Reference, I conclude that FAPI_5_BEHAVIOR shall be defined or FAPI_4_BEHAVIOR shall be defined..

THERE IS A CLASH!

**************************

FIRST and SECOND say that none of them shall be defined, THIRD says that one of them shall be defined.

Could somebody give me a hint what symbol shall I define for FDK 12?

Many thanks in advance.  Zdenek

[Russ Ward]

Zdenek,

What are you trying to do? Are you trying to use FDK 4 code with the FDK 12 or something like that? If you are just trying to write an FDK12 plugin, you don't need to do anything.

I didn't even know these preprocesser #defs existed. My guess is that somebody had an idea to maintain backwards compatibility with FDK code, by means of providing these optional symbols. I would be shocked, though, if it has really been maintained and that it actually works. I would ignore them entirely and just write your code. If you need to compile an FDK client with older code, go get an older version of the FDK.

Maybe I'm completely in the dark here and someone can correct me, but I'm reasonably confident that you can ignore these symbols and its likely that they have no useful function anyway.

Russ

[Zdenek100]

Hello Russ,

thank you very much for your response. I completely understand what you have written. I do not want to define these symbols with the aim to achieve the backward compatibility.

The particular problem sounds like this:

The client I am maintaining calls F_ChannelOpen() function. FDK 12 Programmer's Reference  manual (page 500) says that this function is declared as follows:

ChannelT F_ChannelOpen(FilePathT *path, StringT flag);

However, if you look at the definition in fchannel.h, you will see that the 2nd parameter's type is CStringT in reality (if none of those two FAPI_*_BEHAVIOR symbols defined):

#if defined(FAPI_5_BEHAVIOR) || defined(FAPI_4_BEHAVIOR)

extern ChannelT F_ChannelOpen FARGS((FilePathT *path, StringT type));

#else

extern ChannelT F_ChannelOpen FARGS((FilePathT *path, CStringT type));

#endif

Not only that the real declaration does not fit the programmer's reference document, but the CStringT symbol is ambiguous (conflict with vc\atlmfc\include\cstringt.h ATL::CStringT' declared in vc\atlmfc\include\cstringt.h).

This is my point - I need to resolve the symbol ambiguity.

In my view, the type of the second argument of F_ChannelOpen() should really be StringT as the programmer's reference says but it is defined errorenously in fchannel.h when FAPI_5_BEHAVIOR or FAPI_4_BEHAVIOR is not defined.

Am I missing something or is there really bug in the declaration of F_ChannelOpen()?

Many thanks in advance.

Zdenek

[Russ Ward]

Hi Zdenek,

Interesting observation. I'm not sure what the reason is. I think that anymore, either a bug in the software or an error in the documentation is par for the course.

I have only ever used a string literal with the function, like:

chan = F_ChannelOpen(filepath,"r");

...and I have never had any problems or compiler errors. If I provide a StringT variable instead, VC++ flags the mismatch, but still compiles the application. If I cast the StringT as a CStringT, the mismatch warning goes away.

StringT type;

type = F_ApiCopyString("r");

chan = F_ChannelOpen(filepath, (CStringT)type);

Whatever is the reasoning behind the current declaration, it doesn't seem like a big deal to me. I can get it to work in each logical permutation. Is there something about this that is preventing you from compiling code?

Russ