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