8

If I want to replace a VCL component TXxx should I base my component on TXxx or TCustomXxx?

I am looking to make drop-in replacements for various text-editing components (TEdit, TMemo, etc.) to have WM_PASTE handlers to sanitize inputs to a back-end that is very picky about what it will accept (basically only 7-bit ASCII printable glyphs, spaces, and CR/LF pairs... even tab characters are not acceptable to it). These new components have to go into an existing application, and I want to not do anything I don't absolutely have to in order to make them work exactly the way the old ones did, except for the non-default paste behavior.

I've done one based on TMemo and it seems to work, but somehow or other I have the impression that the recommended approach would be to use TCustomMemo. Is there something I am missing?

wades
  • 927
  • 9
  • 24

4 Answers4

16

By convention, the difference between TSomething and TCustomSomething is that the latter has no or very few published properties so that you can pick which ones to publish yourself. Otherwise there should not be any difference.

1

The way I've always understood the concept of having TSomething and TCustomSomething is when you create your own inheritance of, let's say TButton to your own called TMyBytton. Suppose you want to hide a property, such as Caption (assuming you might not want text). With the TButton, you cannot hide this property. But using a TCustomButton, you can publish which ever properties you want to be visible in the object inspector, and exclude those which you do not want to see. Once a property has been published, it cannot be un-published in further inherited classes.

Jerry Dodge
  • 26,858
  • 31
  • 155
  • 327
0

TObject -> TPersistent -> TComponent -> TControl -> TWinControl -> TCustomEdit -> TCustomMemo -> TMemo

enter image description here

TMemo is just a 'wrapper' for the TCustomMemo control. You can use both but I like to use the Custom version because you derive from a non visual component.

If you want to replace components in future projects you can build an datamodule around the control and manage its properties within the datamodule. After replacing you only have to change the way the datamodule handles the component and not every component in your project.

A1rPun
  • 16,287
  • 7
  • 57
  • 90
-1

Another option would be to simply subclass the respective components like this:

unit SubClassedControls;

interface

uses StdCtrls, Messages;

type

  TEdit = class(StdCtrls.TEdit)
  private
    procedure WMPaste(Message: TWMPaste); message WM_PASTE;
  end;

implementation

{ TEdit }

procedure TEdit.WMPaste(Message: TWMPaste);
begin
  // do whatever is necessary
end;

end.

Then it is important to add the unit SubClassedControls behind the StdCtrls unit in the uses clause of the form. By doing this, you can just continue to use the existing standard controls, but at runtime your application will actually use your subclassed controls. In case you have an existing application with lots of controls this might be an easier way to change the behavior of your controls.

iamjoosy
  • 3,299
  • 20
  • 30
  • -1 because you didn't read the question. You suggest doing exactly what I was talking about, and didn't pay attention to the part that I didn't understand. – wades Jun 25 '12 at 16:17
  • @wades, sorry, my answer was just in response to "...and I want to not do anything I don't absolutely have to in order to make them work exactly the way the old ones did, except for the non-default paste behavior.". And I still think that my solution is by far the simplest for your problem at hand. Of course you can exchange hundreds of controls with your own TMyEdit derived from TCustomEdit etc, but this is far more cumbersome IMO. – iamjoosy Jun 25 '12 at 16:50