Control inheritance – grr…

In the VCL, a common pattern we find is how the controls you actually use at design-time are of classes that in themselves have very ‘light’ implementations, the bulk of the work being done in ancestor classes instead — for example, TListView merely exposes a whole raft of properties introduced with ‘protected’ visibility in TCustomListView.

Now as such, this is all well and good, since it enables making specialised descendent classes that don’t expose irrelevant properties. One quirk caused by it, however, is how the interface definition of most custom controls have to contain a whole raft of entries that just raise to published visibility members introduced in TControl or TWinControl –

published
  property Align;
  property Anchors;
  property BevelEdges;
  property BevelInner;
  //etc.

Consulting a custom control of mine dating from the D7 days, I’ve counted 58 standard members in all needing to have their visibilty explicitly raised!

Given that, wouldn’t it be better if they were published in the base class? In support of this thought, up until D2006 (and maybe with D2009 again too — I don’t have it to check), there was the issue that each new version of Delphi might introduce new members at the TControl or TWinControl level that required explicit exposure. If the custom control writer forgot or missed some out, or indeed, if you were using a control that just predated your version of Delphi, then fixing the problem would require amending the control source and recompiling its packages — a minor pain, but a pain nonetheless. Perhaps because of this, when TControl received new properties in D2006, the maintainers of the VCL directly exposed two of them (namely, AlignWithMargins and Margins) in TControl itself, saving custom controls the bother of having to raise the new properties’ visibilty. ‘Great!’ you might think… until you happen across a case where this behaviour is a pain in the arse.

Specifically, the rich edit 3.0 wrapper I mentioned earlier currently has a published sub-control property, a sub-control that itself has (or had) LeftMargin, LeftMarginInTwips, RightMargin, and RightMarginInTwips properties.  Install it in D2006+, and the thing magically acquires a Margin property that is not only irrelevant in itself (the control is a sub-control, and so has a position determined by its parent in principle), but damn right confusing.  Now, I could hack about things to hijack the ‘standard’ Margins property, backfilling it for D7.  This would still surface two irrelevant members though (Margins.Top and Margins.Bottom), and moreover, leave the XXXInTwips ones adrift.  Grrr!

Advertisements

One thought on “Control inheritance – grr…

  1. Pingback: Tip: removing a property from the Object Inspector « Delphi Haven

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s