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.
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));
extern ChannelT F_ChannelOpen FARGS((FilePathT *path, CStringT type));
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.
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.
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?