We have a Delphi server with remoting SDK.
Besides a Delphi client, we also have two c# clients.
One client, is a WPF client which is used for windows clients on a touch screen, the other one is a Xamarin client.
We have a complextype object, with a field “Description” of the type AnsiString. This contains a string with a euro sign (“foo € bar”)
In the Delphi and WPF client, the data is received in the correct way.
However, in the Xamarin client, it’s received (when I expect the object, right after I received the data from the server) as a question mark (“foo ? bar”).
The Xamarin project, uses a .NET standard library where the connection and data retrieval is done.
I have the exact same setup in the WPF project.
We use a IpSuperTcpClientChannel with a BinMessage to communicate to the server.
Is the parameter or field used to pass this string back declared as WideString or 8-bit Ansi String? In there latter case, it will only be safe to send 7-bit ASCII characters, unless yo can be sure both client and server use the same default code page (which it seems Xamarin might not be doing).
I would recommend to use WideString for anything, these days.
Ok, that’s your problem then. Essentially you just got lucky s far that all your systems were on the same code page.
Two options to fix this:
(a) change the field to WideString — which will break wire compatibility, so you’d need to update all clients and the server to match, in one go.
(b) change the field to Utf8String — which won’t change wire compatibility but will break “logical” compatibility of what older clients will expect in strings. Essentially tally, and clients won’t know to decode the Utf8 and might shoe garage characters instead — but then, that’s really no more broken than it already is, if you’re sending above-7-bit characters ;).
Actually, not exactly the same. The WPF project runs on desktop, so .NET Framework can read locale and default code page used on the host. So it is able to correctly convert received 8-bit value to a UTF-16 char representing euro sign. That said, if/when the client host will have different code page settings than the server host, WPF and Delphi clients will receive incorrect values instead of € as well .
Xamarin app cannot read the required code page, so the string value there cannot be properly decoded from the very beginning.
Solution is to help the binary serializer to decode the value. The BinMessage instance you use has a property named DefaultStringEncoding. Set it to the value matching the code page used by the server app host.
Note 1: I would strongly recommend to set this property in the WPF app as well. Otherwise you’ll have issues with it once someone will start it using a different locale (and thus a different code page)
Note 2: If your server also exposes Data Abstract service(s) and the schema contains AnsiString-typed fields, then you’ll need to set similar property of the Bin2DataStreamer as well.