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

I spent quite a few hours on Saturday working on the application that I discussed here. I started off by working on the database again: I wrote a program that would export the forename, surname and primary key of all the records to an INI file (this is with Window 7/Firebird 1.5, so there are no problems with unicode). Once I had this data outside of the database, I dropped those two fields then redefined them, this time with WIN1255. I then wrote a simple program to repopulate these fields from the INI file. So far so good.

On to the mobile computer with Windows 10, Delphi 10.2 and Firebird 2.5. As I seemed to be unable to use the clientdataset component, I was forced to use a simple query to access the data then display it by means of a listview component. The 'cast' trick worked well and now I could display all the records. I worked on the code to filter these records, and when that was done, I worked on a screen in which the user can edit personal data. As I couldn't use the clientdataset component, I had to create a screen with non-data aware components; this means extracting the data from the database with a query component then loading the data into the appropriate edit boxes. Should the user decide to accept the changes, the data from the edit boxes would be written back to the database with another query. 

This update query was actually a piece of serendipity: when I edited a person's name then wrote the data back to the database (into a field defined as WIN1255), the field in the database became gibberish. Of course! The solution was to add two new fields to the database table defined with character set UNICODE_FSS; the update query then wrote the data to these two fields correctly. But that's not much use if I want to use the WIN1255 fields in the main screen, so I wrote a simple query that updates the WIN1255 fields with the data from the UNICODE_FSS fields cast as WIN1255 (i.e. the reverse of what I had done previously). This actually worked first time!

Then I faced the problem of updating the tree view with the new data: I used the same approach as I use with a grid, namely delete the current record, extract the data for the new record from the database then add it to the list view. This worked on the second time - because I forgot to delete the current node first time around and so caused a key violation.

Whilst walking the dog, I wondered about the clientdataset component: I'm sure that it worked at some stage before I got bogged down with unicode issues. I decided to remove the Delphi installation completely then reinstall; this took a fair bit of time, but once it was finished, the clientdataset component resumed working. So I saved the list view version of the program in a different directory for backup purposes then set about restoring the grid and db controls - this went very quickly. Due to the unicode issues, I decided to continue using the new version of the 'edit person' screen with its non-data aware controls; my approach wouldn't work well with data aware controls as the data is read from one field but written back to another field.

The next stage will be to see what happens when the unicode INI file containing the Russian text is read. I may have to defined duplicate fields with character set UNICODE_FSS for this data. Supposedly the database knows in what language the user completed the exam as there is a language field in the 'people' table, but this field is always empty. I shall ensure that this field receives a value when there is Russian text so that the correct field in the 'results' table will receive the text and eventually be displayed.

With regard to the clientdataset, I wonder whether fields defined in the program (i.e. using the component in 'standalone' mode, not connected to a database) are automatically unicode. This isn't an issue for this program but it will be for the next program that will undergo porting.

And here is the answer to my question about unicode (someone had asked before me): 

You cannot store unicode characters in a field with the ftString field type, you should use the ftWideString field type. Data disappears in a field with ftWideString field type because the size of this field is zero by default. To solve this problem, you should set the Size property of this field to the value more than zero.