Leaderboard

Whilst @dummzeuch makes a good point about us (Embarcadero) wanting to keep a track on NDA breaches I can also see a flipside too which is more in line with what Tommi says. I've made a note to see if we can do something about providing information about compiler conditionals for future betas. Note that for those on the Beta we did allow component vendors and OSS projects to refer to things like "added compatibility for RAD Studio 12" in their release notes and commits as long as they did not refer to or expose any functionality which was specific to version 12. We want to balance the requirement for confidentiality (which is required for sometimes non-obvious legal or technical reasons) against trying to work with repos and Tech Partners to make life as easy as possible and to achieve compatibility as smoothly as we can. All MVPs and Tech Partners are regularly briefed and have several ways to get hold of me directly to ensure communications in both directions are as smooth as possible. For all our users, however, I am here to help be a bridge between Embarcadero's internal teams and all of you - it is quite literally my job. The best way to contact me is by email - ian.barker@embarcadero.com - and I will reply. I don't have all the answers but if I can't help directly, I will speak to colleagues and get the information from the people who do know it. We are listening. I am listening. I work with some truly remarkable, technologically passionate, talented people and we all want the product to be the best it can be, for you to get real value from using it, and for it to improve on an upward curve. That's not some kind of marketing hot air - it's a fact. In cases like this, the version number conditionals and so on being made available earlier, I thought we did this already but if that's not the case then let's see what we can do to improve on that in the future. Ian Barker. Embarcadero Developer Advocate.

Well, that could be a problem if those components are not supported on newer Delphi versions. I don't know because I am not familiar with them. If you do need to replace those components you can make substitute components that will allow loading of the project and will give you if not the same then similar functionality. List all the components you need and find appropriate functional replacement from the Delphi version you plan to upgrade. Then create package your own set of components that will have the same names as TNT components and inherit from appropriate components in new Delphi. Then add all the properties they have that might be different. You will also need to hook up and implement appropriate functionality behind those properties, unless they are functionally unnecessary and you just need to have dummy property to allow loading of a project in new Delphi. This set of components and controls will allow you to open the project in new Delphi version and use those as replacement for TNT components without the need to change form dfm files. It is important to make all those preparations on small test project so that you have everything working properly before you move your actual project. Unicode Delphi also has a WideString, so in theory you could keep using it, but if you are using WideString to interact with TNT components you may need to replace those to generic string type in new Delphi instead of introducing WideString properties to your TNT replacement components.

You can always tweak the source of DUnitX.Loggers.GUI.VCL.pas to your needs. Currently the code for saving is located in FormClose. Besides extracting it to a dedicated method, it can be inserted at the beginning of RunExecute. In Contributing.md you find instructions to make your enhancements available for all.

Possibly. Depends on the context in which it's being used. In any case, if you need UTF-8 strings, you should use the native UTF8String type instead of AnsiString (even in Delphi 7, you should have been doing that). If you must use UTF8 encoded AnsiString in D2009+, at least use SetCodePage() to make sure the CP_UTF8 (65001) codepage is assigned to its data. UTF8String and UnicodeString are assignment-compatible in D2009+, the RTL will automatically convert between them without any data loss (in Delphi 7, you would have had to use the UTF8Encode()/UTF8Decode() functions for that). At least with SetCodePage(), you can make sure not to lose any data if a UTF8 encoded AnsiString is assigned to a UnicodeString (the reverse is not true, though).

Low-level experienced, I'm still learning. Android has a layer of complexity above Linux kernel. Socket API on Android is the same a socket API on Linux. Before entering to TWSocket port, you should begin with the simplest program which open a TCP client socket with pure API, and send any string and wait for the answer, display it on a TMemo and then close. A simple TForm with a TButton and a TMemo will be enough. Use one of the server samples in ICS for Windows to connect to. You can find simple C-code for Linux that you can start with. If you are able to port this C-code to Delphi/FMX for Android, then you are probably ready to start porting ICS. If you want to discuss further, please open a new topic with proper subject to catch attention of interested peoples. Maybe some will help.

This was the exact approach I took to convert our legacy application to 64-bit. Our custom component package took about 2 days (plus 2 to fix issues which weren’t obvious), the program itself (1,5M loc) was only one day (plus 7 for fixing the same). I’m not saying it’s the most sophisticated method but it’s one of the easiest and definitely viable.