Completing the story of porting an application to Windows 10/Delphi 10.2

The previous installment of this story had the application displaying people's names in unicode and allowing them to be edited. This means that the remaining parts are to read in the INI file that contains the answers from the user and then display them, via HTML and thence to Word.

Initially I tried saving Russian text into the database table via the database manager program, outside of Delphi. This was spectacularly unsuccessful so eventually I created a new database with the same structure but with the default charset UTF8. I then copied (by means of a simple program that I wrote) all the data from the old database to the new database, using the 'cast' trick (cast (surname as varchar (16) character set unicode_fss)) wherever necessary. I then renamed the original database to 'OldWhoAmI' and renamed the new database to 'WhoAmI'. Then I unregistered both databases from the database manager then registered the new one. This version allowed the saving of unicode text, especially Russian.

Once the database issue had been settled, it was much easier to continue porting the application. I restored the 'edit person' screen discussed in the second episode of this series to use data aware components; there was no need for tricks using 'cast' as the text was now unicode. Reading the data file, including Russian, required no changes that I can recall. 

Creating an HTML file that could be sent to Word required a few changes. Until now, I have been using the 'AnsiToUTF8' procedure whenever I wanted to output Hebrew; this is now superfluous so I had to remove all these calls. I also had to update all the Hebrew that was embedded in the program code. Once I had an HTML file that displayed correctly, I tried to export to Word; I received a mysterious error message, informing me that my file could not be found. Initially I thought that this meant my HTML file, but then I realised that it meant that the template could not be found. Once I updated the template, I could export the data to Word.

Conclusions for next time:

1. Create a new database with the same table structure but with the UTF8 charset. Copy all data, using casts wherever there is Hebrew text.
2. Register the new version of the database in the database manager (this isn't essential but it helps).
3. Save the database in a specific directory.
4. Porting is fairly simple. AnsiToUtf8 calls should be removed when HTML code is developed.