I cannot move forward with my project because of RemObjects.
I am moving to a new computer and installed the latest RemObjects version. (Note to mention getting an exception “’’ is not a valid GUID value” that is still there although I interacted with support 6 months ago about this and no solution besides recompiling, which has to be done with each upgrade/installation).
In the service builder, I have a service with methods (“Operations”) with parameters of AnsiString type. In 8.x and previous, this was fine. In 9.2, these create an interface with String type, which creates compiler exceptions with all my methods.
I sent an email to support@remobjects.com on this issue with screen shots and compiler exceptions, but the support page (http://www.remobjects.com/support/) says I should get an auto response and have not. So I re-post it here.
in 9.2 we got rid from using Ansi/UTF8String in favour of Linux support where is these types are not present
data serialization wasn’t changed, i.e. data are still serialized as before: if parameter is declared as AnsiString, it will serialized as AnsiString.
{.$DEFINE CODEGEN4_LEGACYSTRINGS} define in RemObjects.inc can be uncommented for using legacy generation with AnsiString/UTF8String
of course, rebuilding of RO packages are required after changing of RemObjects.inc
latest beta of ROD/DAD already contains similar option in ServiceBuilder
Note: TDataAbstractService is already using new style w/o AnsiString / UTF8String types so it may require manual updating of some methods like Login / LoginEx
I’m disappointing that for Linux support you break a lot of existing code. (I would understand if you allowed for Linux support with a complier directive change, and announce that in the next version it will be the other way around). I have a lot of other things to do besides figure out how to get RemObjects to work.
as I see, you don’t use DataAbstract, so just enable {.$DEFINE CODEGEN4_LEGACYSTRINGS} and codegen will generate _Intf, _Invk, _Impl as before with AnsiString and UTF8String
another benefit from getting rid from using Ansi/UTF8String is performance burst.
our tests shows much better performance in comparing with ROD 9.1 on the same RODL
we have a lot of conditional in our code because we supports all versions of delphi since D7 and Lazarus/FPC so adding a new one isn’t good and will make mess in code
Just to be clear, without any warning that at least I saw, your changes broke a lot of code; I had to wait several days before I got a response to my post–this should have been easy to answer. And while I appreciate the improved performance, it would be nice to get some compiler warnings about it in a version (e.g. 9.x) before being forced to wade through these changes–or at least a message when I open the Service Builder dialog that the ansi strings in the ROLD file are being changed. This just isn’t cool.
i apologize for the trouble this has caused you. The string change was an advetrised change for 9.2, made in an effort to keep up with Delphi’s continuing changes (and repeated inconsistencies, unfortunately) to its string type. We don’t make breaking changes to RO lightly (and in 13+ years, we have very few), but sometimes we just need to move forward.
We’ll try to make these kind of migrations easier in the future, shook the need for one arise again.
My problem with this change is, my product has na embedded client update mechanism using RO. Now, my concern is, the old clients compiled against old RO are using AnsiString. This breaks compatiblity. So, I think, I also need a good compatiblity option for the next year.
I would suggest an compatibilty flag in the RODL, forcing AnsiString to be handled always as AnsiString.
this change should not affect wire compatibility at all. it only affects how the ansistrings are handled in code. if your rodl is defined as ansistring, your data will continue to be sent as ansistring, and old clients (or servers) will be none the wiser about it…