C++ AdFax.hpp E2109 Not an allowed type

[dan27125]

+++++++++++++++++++++++++++++++++++++++++++++FIX C++ compiler error E2109 Not an allowed type in AdFax.hpp.
++++++++++++++++++++++++++++++++++++++++++++++

I'm a C/C++ programmer with very little Delphi Pascal experience. I have a high volume outbound Fax Server APP that was built 20 years ago using C++ Builder 6 and a AsyncPro. I recently got the app to compile and run OK using C++Builder/Rad studio version 10.3 Tokyo. However, when using C++ Builder to compile my fax outbound fax app I was getting compiler error E2109 Not an allowed type in a number of places within AdFax.hpp. The HPP files are generated when you build the C++ package. For some reason when the package is compiled "__published:" on some items is a problem when the HPP files are created.

For troubleshooting I can manually edit AdFax.hpp, change "__published:" to public: in about 6 changes one line changes to a number the C++ classes similar to this.... The app compiles and runs OK with 10.2 Tokyo. But under 11.x Alexandria it crashes. I'm a C/C++ programmer with very little Delphi Pascal experience. From what I've read about Delphi Published vs Public, the latter, public omits run time type information. I suspect the edit to AdFax.hpp changing from publish to public is not a safe valid fix because its changing intended run time type information

Could you help me figure out how to fix the Delphi / Pascal code ?

Searching online I found something similar error from almost 20 years ago

https://sourceforge.net/p/tpapro/discussion/241882/thread/823a8ad8/

Here is an example of the changes one line changes to a number the C++ classes similar to this....

class PASCALIMPLEMENTATION TApdReceiveFax : public TApdCustomReceiveFax
{
typedef TApdCustomReceiveFax inherited;
__published:

public: // DGA change to public to fix C++ E2109 Not an allowed type

__property AnswerOnRing = {default=1};
__property FaxAndData = {default=0};
__property FaxNameMode = {default=1};
__property OneFax = {default=0};
__property ConstantStatus = {default=0};
__property DestinationDir = {default=0};
__property OnFaxAccept;
__property OnFaxName;

public:
/* TApdCustomReceiveFax.Create / inline __fastcall virtual TApdReceiveFax(System::Classes::TComponent AOwner) : TApdCustomReceiveFax(AOwner) { }
/* TApdCustomReceiveFax.Destroy */ inline __fastcall virtual ~TApdReceiveFax(void) { }

};

[romankassebaum]

Here it is the same, please contact David Millington.

[dan27125]

Do you know what a string literal is in Delphi Pascal?  How much Delphi Pascal experience do you have?There are a few Delphi, Pascal string literals within the library that are causing problems.About 15 years ago, somebody changed a few of them, removed the literal braces at the end, changed it to say just string.And they put comments and posted on stack overflow that this change was necessary to accommodate C++ builder, not liking string literals.Maybe this is what happened?Irregardless, who’s to say these changes were exactly correct?I am not fluent in Delphi, Pascal, so it’s not clear to me what the rules are for string, literal versus no literal at all, IA, removing the braces.Within the C language, when you put braces and specify a number, your allocating, an array of X number copies of that particular object.When you remove the braces, you’re only getting one copy of that object,If there is Delphi, Pascal code that is indexing an array then it better have enough members Look on sourceforge  version 5.x of asyncpro. Examine those changes to the string, literals, and then examine anything you forked, and where are you derived it from.Irregardless, if you or anybody with Delphi, Pascal experience could look , and determine appropriate changesSent from my iPhone On Feb 28, 2023, at 9:27 AM, Roman Kassebaum ***@***.***> wrote: Here it is the same, please contact David Millington. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[romankassebaum]

I explained everything here: #35.