FORCE_ANSI_STRING causes compile error

[SevenOut]

Using Delphi XE6 Update 1 with RTC 6.36

I'm building an iOS app that will be connected to a Windows host.  I started with a test Windows app and had 100% success having the iOS app and the Windows app communicate with each other.

The problem I ran into is when I went to connect the iOS app to the official Windows host that was built in Delphi 2007 with RTC 2.70.  I could get the connection to be made, but none of the function calls were going through.  I thought about it and it occurred to me that it was maybe an AnsiString versus UnicodeString issue.  I saw that there is a FORCE_ANSI_STRING compiler directive that should make the iOS app use AnsiStrings instead of UnicodeStrings.  I added the FORCE_ANSI_STRINGS directive to the Project | Options and then did a Build.  I then got the following errors:
[DCC Error] rtcLog.pas(98): E2004 Identifier redeclared: 'Log'
[DCC Error] rtcLog.pas(102): E2004 Identifier redeclared: 'Log'
[DCC Error] rtcLog.pas(107): E2004 Identifier redeclared: 'XLog'
[DCC Fatal Error] rtcFastStrings.pas(657): F2063 Could not compile used unit 'memStrIntList.pas'

Any help on this?

Thanks
Scott

[D.Tkalcec (RTC)]

The FORCE_ANSI_STRING compiler directive can ONLY be used on Win32 and Win64 Projects and should ONLY be used if your code does NOT correctly handle the new String type, which is mapped to UnicodeString since Delphi 2009. On mobile platforms, when using the NEXT GEN compiler (Delphi XE4 and later), there is no AnsiString type. This is why you get these compile errors when trying to compile your iOS Project with XE6 after declaring FORCE_ANSI_STRING. To fix these compile errors, remove the FORCE_ANSI_STRING compiler directive declaration from your Project Options.

Your problem with unhandled requests is probably a result of your iOS App running on a mobile device and using a mobile internet connection provider, which is sending HTTP requests to the Server as if the Server was a HTTP Proxy, adding "http://" and the domain name in front of each request, which the Server is NOT expecting, so the requests remain unhandled.

Please, read this Quick Start topic for more info about fixing that problem.

You will need to update your Server Project to use a newer RTC SDK version, though, because the FixupRequest.RemovePrefix property was added in RTC SDK 3.12, so you won't find it if you are still using RTC SDK 2.70. Unless you are still using Delphi 6 or older for the Server Project, there should be no problems updating your Server Project to compile with the latest RTC SDK version. You can use the FORCE_ANSI_STRING compiler directive there, if you want to make sure the Server Project will continue using the AnsiString type on Windows platforms instead of the new Unicode String type. Just don't try using FORCE_ANSI_STRING on Projects which you want to compile for mobile platforms, because this can not work.

Best Regards,
Danijel Tkalcec

[SevenOut]

Understood.  I've already removed the FORCE_ANSI_STRING directive from the mobile project.

For the time being, the server app needs to remain a Delphi 2007 Win32 app.  I don't think there will be a problem updating from 2.70 to 6.36 with that app.  I try that today.

I'll try the RemovePrefix property and see if that fixes things.  BTW, I'm only operating on a local WiFi network and not going through any mobile Internet service.

Scott

[D.Tkalcec (RTC)]

I'm only guessing now, but if your Client was using a local WiFi connection, the problem might also be related to some changes to the RTC remote functions protocol between RTC SDK v2.70 and v6.36. Updating your Server to the latest RTC SDK release should fix the problem with the new mobile Clients compiled using the latest RTC SDK release and Delphi XE6, but it might also result in the Server to stop working correctly with your old Clients, if they remain compiled with the old RTC SDK version. You might need to recompile all your related Projects (Clients and Servers) using the latest RTC SDK version to keep them all compatible.

Best Regards,
Danijel Tkalcec

[SevenOut]

Well, it appears that simply updating to the new 6.36 version was enough to make it start working.  No FixupRequest changes were needed.

I still have some more testing to do to test all the functions and data being passed back and forth.  I have high hopes that everything will work just fine.  I'll replay here if anything else comes up.

Thanks
Scott

[D.Tkalcec (RTC)]

Thanks for your feedback. I'm glad the update did the trick.

PS. Unless your Server is also a Proxy, forwarding requests to other Servers by analyzing the "http://domainname" prefix, I also recommend setting the FixupRequest.RemovePrefix property to TRUE, to make sure there won't be problems with Clients running from mobile devices and using mobile internet connection providers.

Best Regards,
Danijel Tkalcec