Third-Party Data Module Issues with Delphi 5 Update Pack 1

By: John Kaster

Abstract: This article describes potential issues with third-party components using undocumented features of the Delphi 5 Data Module designer components

Third-Party issues with Delphi 5 Update Pack 1 (UP1) Data Modules

By Jeff Overcash (TeamB) (edits by John Kaster, so blame me instead of Jeff for any errors)

If you are using components that rely on the unsupported TSprig class, these components will probably not work after UP1 is installed. The TSprig class is an undocumented design time component class, primarily because the Delphi R&D team planned on making changes to it before publishing how it should be used. Once a class is documented, we ensure backward backward compatibility whenever possible, so it makes changing a class less flexible.

The symptoms to the issue are fairly simple. After applying UP1, which changes your Delphi version from 5.0 to 5.01, a component will give an AV whenever it is dropped onto a Data Module or a Data Module with the "bad" component loaded. You can not even save the Data Module when it is in this state.

This is being caused whenever the components have a design time package that is registering a TSprig or other of the helper class descendant for the Data Module designer. These classes are used to enable the drag 'n drop and other new capabilities in the Delphi 5 designer. The UP1 designer introduces some new virtual functions to these helper classes. Therefore old design time packages that descend from these classes will have v-tables that point to the old interface of these parent classes. This will cause an AV when the descendant tries to call a virtual procedure since its v-table no longer points to the correct procedure due to this mixed offset state.

What to do about it

In most cases, a design time package compiled against Delphi 5.01 will solve the problem. The new Data Module designer should recognize TDataset and TCustomConnection descendants, and provide a menu dialog based on the registered component editors when the right mouse button is used on a component listed in the tree view.

This fix does not require any code changes, but it does require that the design time package be compiled against the new Data Module designer helper class interface to get corrected v-tables. This does mean that third party vendors will have to maintain two sets of design time packages, one for Delphi 5.0 and one for Delphi 5.01. You can not mix and match versions of the design time packages. (This is another good reason to avoid using undocumented features.)

This is only a problem for the few component writers who have written these helper class descendants. These classes have not been documented in Delphi 5 yet because interface changes were planned, but example code was included in the new property editor source directory, so ambitious developers used this code to enhance their products. Most design time packages are not affected by this issue.

There is a reverse problem as well. If someone tries to use a design time package that is compiled with Delphi 5.01 and tries to use it in Delphi 5.0, they will get an error message and Delphi will refuse to load the package during start-up. Once again the only solution is to use a package that is compiled against the correct design time interface.

Sample Package Load Error Message

The UP1 patch for both Pro and Enterprise comes with correctly compiled design time packages for InterbaseExpress and the BDE database components. Enterprise comes also with an updated ADOExpress design time package.

Known packages that will have problems.

  • Delphi 5 Pro user with ADOExpress who applies UP1 but does not apply the ADOExpress patch.
  • InterbaseExpress users who apply UP1 and also try to apply the beta update that is on the InterBase web page.

Borland C++ Builder 5 ships with the same Data Module designer code as the Delphi 5 UP1, so if someone tries to load a Delphi 5.0 design time package that would fail under Delphi 5.01 it will also fail under BCB 5.

Borland has a fairly strong policy of not changing the run time interface of the VCL on minor version updates. In this case as well, this is not a change to the run time interface because it is not a published feature of the run time interface. These components are for internal use only until documented, and as such are subject to change without warning.

Only one time in the history of Delphi has the run time interface changed in a patch. While Borland also tries to limit design time interface changes like this, it is not always possible to fix some design time bugs in a patch without changing the interface to a design time class.


Server Response from: ETNASC03