I’ve just updated my RO from the version I had (1463) to the last one available now, 1533, and have found several issues:
The known ones: having to disable the UseGenerics option, because of the bug on the linker that makes it impossible to link the RO libraries with that enabled; having to fix some of the headers created by the compiler, to avoid compiling errors (specifically, uROSocketUtils.hpp, to remove the typedefs and the consts that use those typedefs).
But know I am seeing errors in the _Intf and _Invk units created with this new version:
The _Intf unit has a TLibraryAttributes class, which as-is can’t be compiled because the forward declaration just below the namespace is class DELPHICLASS TLibraryAttributes but the actual declaration omits the DELPHICLASS. This can be fixed easily by just adding the DELPHICLASS to the actual declaration.
In the _Invk unit the constructor for each of the services on the RODL includes a FAbstract = false call, which fails with an error “E2451 Undefined symbol 'FAbstract'”. I guess one can just remove that line from each constructor, but it’s the same: having to fix this files everytime they are generated is practically impossible, as they are generated by default every compile…
So far this is what I have found, but I haven’t finished compiling even, so I don’t know if there would be more surprises ahead…
Any ideas? Did I miss something while compiling/recompiling RO-SDK?
I saw in some posts about the changes the RemObjects_user.inc feature, will do like that from now on.
The problem with uROSocketUtils: I believe that some of those lines are actually already generated by {$EXTERNALSYM} directives? at least the typedefs I’m almost sure. I’ll check the unit source and let you know. In my case I just comment those lines. It’s not common to use those consts from outside the RO-SDK source, I would think, and I have never needed them. I have to do that kind of commenting-out in several libraries.
About the TLibraryAttributes class… I don’t know how it works there. Here it always creates the class without that attribute so the compiler always gives an error that there is a mismatch between the two declarations.
And about the fAbstract, ok, I’ll add that line (I removed them to be able to keep on compiling).
I actually have disables the creation of the _Invk and _Intf units in most of my projects as a rule (there are no frequent changes to the RODL anyway), so I’ll keep like that for the time being.
I don’t have RAD Studio 11 here to try. I’m working with 10.1 Berlin. I’m not sure if that would make any difference, though, as the error does make sense as far as I can see:
[bcc32 Error] tsInfo1_Intf.h(121): E2356 Type mismatch in redeclaration of ‘TLibraryAttributes’
Full parser context
UsoSistemas_Impl.cpp(14): #include tsInfo1_Intf.h
tsInfo1_Intf.h(38): namespace tsInfo1
[bcc32 Error] tsInfo1_Intf.h(106): E2344 Earlier declaration of ‘TLibraryAttributes’
Full parser context
UsoSistemas_Impl.cpp(14): #include tsInfo1_Intf.h
tsInfo1_Intf.h(38): namespace tsInfo1
In any case this can be easily solved with the DELPHICLASS attribute on the definition of the class itself. My guess is that it is needed for this class as it does not inherits from any other class (which is the case for the other classes defined on the _Intf, and don’t have the DELPHICLASS attribute on the definition, just on the forward declaration)
Actually, looking at the DELPHICLASS macro, it says:
define DELPHICLASS __declspec(delphiclass, package) // Delphi-style class (derives from TObject); may reside in a package
So in theory then the TLibraryAttributes class should be inherited from some TObject related class. As far as I know this classes are handled differently from other “pure C++” classes (which would be the case as is) by the memory manager/compiler/linker.
I just saw a more important bug with the _Intf codegen:
The new version of the _Intf uses a new function for the different types: ReadSomeTypeWithErrorHandling. This function asks for an lvalue, but the code passes a pointer (as it was before):
Ilve installed the latest version .1537, and everything seems to be working fine, except one thing:
There is, on the _Intf code, a call to lMessage->SetAttributes. For what I can see, it uses the things one defined on the attributes section of the Service. But on C++Builder the call is incorrect, it produces the error:
[bcc32 Error] msaCI_Intf.cpp(236): E2034 Cannot convert 'OpenArray<TVarRec>' to 'const UnicodeString *'
Full parser context
msaCI_Intf.cpp(229): parsing: int _fastcall TSvcGeneral_Proxy::Login(const UnicodeString,const UnicodeString,const TTipoModulo,const UnicodeString,const bool,UnicodeString &,UnicodeString &)
I have just started testing the attributes stuff, so I can easily remove them and workaround the bug right now. But this needs to be changed for it to work. According to the declaration of SetAttributes you would have to change this for something like this:
I’ve just found another little issue: When creating a service that has an Ancestor, when creating the _Impl units for C++ the #include used for the Ancestor unit is, for instance:
#include "BaseService_Impl.hpp"
But the units are generated as cpp/h pairs, not cpp/hpp pairs. So it should be just:
