Yesterday was a very strange and frustrating day. Inbetween the many times
that I spent in our security room, I continued to work on migrating the
management ERP program to Delphi 12/Unicode/Win11. I continued in the same
vein as Friday, migrating the forms needed to create a minimal version of
the program that actually does something.
By about lunchtime, I had a clean compilation with maybe 30 different units
(I haven't counted them) but when I came to run the program, it didn't
progress after the splash screen, displaying the error 'Class FMTBCD not
known'. I recognised this name as it is one of three units (the others being
SqlExpr and Provider) that dbExpress adds to units that use that kind of
database component. I hadn't been diligent in deleting these units from the
source files, so first I had to do a global search then removed them from
about 15 different units.
After recompiling, I still had this error, so the next step was to look for
persistent field variables defined as TFMTBcdField (or similar). There were
a small number of such variables, but replacing them was problematic as that
definition came from the DFM files. So I added some more replacement rules
to the DFM migrator to handle this case. I should point out that sometimes
adding what seems to be a simple change to the migrator is actually quite
complicated. For example, I had some such fields that had to be redefined as
TFloatField, but as the fields in the original DFMs had properties such as
'precision' and 'size' that TFloatField does not have, these lines
have to be excluded from the transfer - not so easy. These changes are
required because Delphi 12 Community Edition deliberately excludes certain
types.
Even after changing the type of these variables, I was still getting the
error message. Eventually I tracked it down to one specific query in the
data module, an 'invisible' query that has several fields defined as BCDs.
Changing these was very difficult but eventually I succeeded. But was that
the end of my problems? No - first there was TMemoField then TSmallintField.
Fortunately it was easy to overcome these problems by directly editing the
appropriate DFM file.
Then when I thought that I had a clean compilation and no run time errors,
Windows' Access Control had to stick his ugly head into the process, so I
had to spend a frustrating hour or so getting a certificate, saving it into
the certificate manager and thence into the Delphi compiler. Fortunately I
won't have to do this again, although I may have to copy what is equivalent
to a small batch file when I work on another program.
Finally at about 7 pm, after a very long and stressful day, the program
compiled and actually ran. I could bring up the list of customers! This may
not seem much, but to get this far required fixing and compiling many units
and overcoming what can only be described as overhead. Of course, very
little on this form works at the moment, but the remaining problems here are
relatively easy to fix.
And once that's done, then I'll have to start the process over again,
finding important forms that need to be compiled and then the units that
support those forms. The 'DoCustomers' form is used for three different
tables and requires 18 different user forms in its 'uses' statement, so
completing this form will be an important milestone. Then there is the
'DoDockets' form with about 20 different supporting forms, and the
'DoTables' form with maybe 30 forms. Once these are completed, then 'there
only remains' about 40 report forms, but these should be relatively simple
to migrate as they are all based on the same template.
This day in blog history:
