marco
cantu

Mastering Delphi 3

Updates

Although I've tried to check every single page of the book with care, there is no way a 1500 pages book can be complete correct. The book "Mastering Delphi 3" was also released at the same time of Delphi 3, so I failed to notice few of the final changes of the software in time for printing. The list of errors and omissions, sorted by chapter and page, is followed by a list of further hints and tips.

Beside the technical errors there are two small problems with the cover. The text close to the CD icon should read "More than 300 Delphi Examples" (not "Objects"). The "Second Edition" tag is a little confusing, because this is actually the third edition. Seems this has to do with the fact this is the second edition covering a 32 bit version of Delphi, or with the fact that the title changed for the second edition, I'm not really sure...

Errors and Omissions (Errata)

Further Hints and Tips (Addendum)

Packages are special DLLs

It seems that many programmers think they can apply their knowledge about DLLs usage to packages (I did this error myself). Building a small EXE and several DLLs is a typical way to make a program more flexible (you fix a bug in small DLL and ship only that to your clients). You simply CANNOT use packages this way, because packages include version information! The effect is that if you recompile the package-DLL, you need to recompile all the executables files based on the package-DLL. Otherwise starting the program will produce a Windows error, almost incomprehensible to users (something like: Cannot find package:unit:method). Seems there is no obvious way to make the program die gracefully. This is a problem of the Windows loader, which loads the DLL and tries to fix the import table of the executable file... but doesn't find a proper match!

So packages are just for components distribution, and I strongly advise against using home-built packages at run-time! Of course the incompatibility takes place only if you do changes in the interface section of one of the units of the package: If you only edit code in the implementation section there will be no problem. However, since packages are meant as component packages, every time you change the interface or even add something to it without changing the existing code, all the programs using the previous version of the package will be broken. A solution is to add the version number inside the name of the package DLL: If mypack01.dpl becomes mypack02.dpl the older programs still works. The drawback is that you might end up with ten versions of a package on disk, and not be sure which are actually in use. I think the new CDK (the Component Developer Kit from Eagle Software) uses this approach.