Custom Component Development in Delphi
Everything about creating custom components in Delphi. The ultimate source.
That's why you love Delphi! I think we can all agree: components are essential elements of the Delphi environment. One of the most important features of Delphi is that we can use Delphi to create our own components. We can derive a new component from any existing component, but the following are the most common ways to create components: modifying existing controls, creating windowed controls, creating graphic controls, subclassing Windows controls and creating nonvisual components. Visual or not, with or without property editor, from scratch...you name it. Developing Delphi components isn't a simple task, it involves quite a bit of knowledge of the VCL. However, developing custom components is not an impossible task; writing components is just pure programming. Articles, papers, tutorials What follows is a list of articles that deal with custom component development in Delphi.
Fullscreen Accessing protected members of a component Many Delphi components have useful properties and methods that are marked invisible ("protected") to a Delphi developer. In this article you will find the workaround to this problem - thus enabling you to access a DBGrid's RowHeights property, for example. Creating Custom Delphi Components - Inside and Out This tutorial will explain component writing to you, which should result in more code reuse. It will go over properties, events and methods, and will also explain how to install components. The final part of this tutorial is about Object-Oriented design. Creating Custom Delphi Components, Part I This first part demonstrates some of the best approaches to building components, and at the
same time provides tips on deciding on the best base class to inherit from, using virtual declarations, the complexities of overriding, and so on. Creating Custom Delphi Components, Part II Quite often it is necessary to write components that perform more advanced functions. These components often need to either reference other components, have custom property data formats, or have a property that owns a list of values rather than a single value. We will explore various examples covering these very subjects, starting with the most simple. Ads
Custom Web Development Delphi Controls Delphi Developer Website Development Class Delphi Component
Creating Custom Delphi Components, Part III This article is the final part of a three part article on components. Part one covered the basic creating of components, part two covered how to write advanced properties, how to write custom streaming for those properties, and sub-properties. This final part will cover property / component editors, how to write dedicated editors for your component / property, and how to write "hidden" components.
More resources First, if you want more, consider buying a book on Developing custom components. Second, why not try locating an existing (with source perhaps) component you are looking for. Third, when you are 100% sure there is no such question on custom component development you can't answer...there will be something that you don't know. Everything you have to do is to ask a question on the Delphi Programming Forum and wait for answers. If you still need more samples .. try the second page ... Articles, papers, tutorials Here is a list of articles that deal with custom component development in Delphi.
VCL Component Messages [RTF] Component Messages (CM_) are generated only by the VCL and are not reflected Windows Messages (WM_), as one may assume. In spite of that Component Notifications (CN_) are reflected Windows Messages. The idea behind it is, that Windows often sends messages to a parent window of a control instead of the control itself. The VCL simply converts (reflects) these messages to Component Notifications and then sends it to the control, for which the message originally was meant.
Delphi Component Building. In this article, read about every aspect of Delphi Component building. Design a TTicTacToe component and learn about: how to build our own components for
Delphi, how to add properties, methods and custom events to them, how to wrap them around DLLs, how to install them, how to design a palette bitmap and write online help to support the component user. continue reading below our video
Building SuperComponents in Delphi [download] SuperComponents, also known as aggregate or compound components, are collections of existing sub-components and their relationships combined into a single component. The collections are typically arranged inside a container parent component that manages the visual layout of the sub-components.
Accessing protected members of a component Many Delphi components have useful properties and methods that are marked invisible ("protected") to a Delphi developer. In this article you will find the workaround to this problem - thus enabling you to access a DBGrid's RowHeights property, for example. Have you ever caught yourself in talking to yourself? A discussion like the one below perhaps? "Hmm, that DBNavigator is really cool, but if I could only lay my hands on the buttons and those pictures it displays?", or "I could really use the OnClick event for the DBGrid, but why is it not accessible in the Object Inspector?!", or "If I could just change the height of that title row in the DBGrid". A little OOP story... As you probably know (and those who do not will learn now), in Delphi OOP the protected data of a class is accessible to any method that appears in the same unit as the class. In Delphi class declaration, every member of a class has an attribute called visibility, which is indicated by one of the reserved words private, protected, public, published, or automated. If you are not familiar with the meaning of those keywords, please read at least some of the pages of the "Creating Custom Delphi Components - Inside and Out" article. Recall the self-dialog above, what if you really need to get your hands on the Height property of the first row (where titles are displayed) of a DBGrid component. In this article, you'll find out about a technique sometimes called the "Protected Hack" - deriving (subclassing) a component from an existing Delphi component with the only purpose or exposing the protected properties and methods. Note: Another workaround to this "problem" is to create a new component derived from the component you want to hack and make the properties either public or published. This would end up in installing the new component on the Palette so you can access it from everywhere. However, many times you'll only need to expose only one property or method (presumably limited to a single unit in your code) - why bother with creating a whole new component? "Protected Hack" The general technique explained here can be used to surface hidden (that is, "protected" in Delphi OOP jargon) properties and methods for Delphi classes (components). If you know that an ancestor could do something (handle an event, access a property, execute a method) this is how to make the descendant do it:
Let's say we need to hack a DBGrid. What we want to access is the RowHeights property. Make sure you are editing the unit where the DBGrid is declared (for example: DBGrid1 dropped on Form1, so we are editing the Unit1.pas) Create a noticeably worthless derived class:
THackDBGrid = class(TDBGrid); Apparently, the class THackDBGrid derived like this does not bring any new functionality to DBGrid. Though, it does provide the *free* access to all the protected members of the DBGrid component. To use once protected members, you must typecast the component you refer too to the new (descendant) class.
Now, let's see some Delphi code. Assume you have a Delphi form (Form1) with a DBGrid (DBGrid1) displaying some data. To access the protected RowHeights property of that DBGrid you first hact the DBGrid comonent. Here's the portion of the Unit1.pas unit - where Form1 is declared: uses Windows, Messages, ..., Grids, DBGrids, ... ; type THackDBGrid = class(TDBGrid); type TForm1 = class(TForm) DBGrid1: TDBGrid; .... Note the THackDBGrid declaration! Now, to change the height of the title row of the DBGrid1 you simply typecast DBGrid1 to THackDBGrid like: //makes the Title's row 20 px in height (if displayed) THackDBGrid(DBGrid1).RowHeights[0] := 20; Ok, that's it. RowHeights?! Yes, the RowHeights property of a TCustomGrid (the TDBGrid derives from) gives the height (in pixels) of all rows in the grid. In TDBGrid this property is protected - in THackDBGrid it is editable! Note that the next assignemet gives the compile time error: "Undeclared identifier: RowHeights". DBGrid1.RowHeights[0]:=20; It's working! ... Howcome? Yep, it is. This is why: the THackDBGrid automatically inherits all the protected members of the TDBGrid (and all public, private, etc. of course), due to the fact that THackDBGrid is in the same unit as the code that accesses the protected property, the protected property is available. Note: do not think that you can define the THackDBGrid in another unit - the code will no longer compile. Another approach - no type-casting. If you need to access the protected members of a component but do not want to use type casting, you can declare the new (hacked) class with the same name as the old class: type TDBGrid = class(DBGrids.TDBGrid); Now, when accessing any protected member, you do not need to use the THackDBGrid(DBGrid1).Something syntax; Delphi will use the modified component as if it were the old one. Therefore a line like DBGrid1.RowHeights[0]:=20; will compile. Warning! This is a hack - a very bad OOP technique. There are reasons that components do not expose certain members of their class declaration. Use the technique explained in this article at your own risk.
Note: "a hack" - means that it breaks standard OOP practices. This "hack" works (and will work in future Delphi version) because it relies on a specific Delphi Pascal OOP feature.
Creating Custom Delphi Components - Inside and Out Page 1: About components, properties, methods and events Article submitted by: Alistair Keys What's This Tutorial About? This tutorial will explain component writing to you, which should result in more code reuse. It will go over properties, events and methods, and will also explain how to install components. The final part of this tutorial is about Object-Oriented design. What Are Components? Components are simply little bits of an overall system. If you have had any experience with Object-Oriented design, please don't shoot me for such a simplistic explanation - I'll do better, honest ;-). Components can help code reuse - if you find yourself repeating the same code, you can write a component for your task and place it on future projects with two mouse clicks. Have a look at the Delphi component palette. You will see all sorts of objects - buttons, checkboxes, shapes and so on. If you find you have a recurring task that is getting pretty monotonous, you can create a component to do the job for you. Once you've finished it, you can install it and use it like any other. Properties Properties are data held by the component. An example here would be a "car" component, which would properties for "PaintColour", "Manufacturer", and so on. You can consider properties to be just variables, although they are more complex than that. When you are defining properties, you usually specify three things: its data type, how to read the property and how to write the property (if applicable). The first is obvious; if you want the property, you need to know what it is actually representing! The next two aren't quite as obvious. Accessing properties seems straightforward... we've all done it (e.g. "Button1.Caption := 'xyz';", where we're accessing Button1's Caption property). This just seems like a simple variable assignment, and that's probably what you assumed it was. Well, it's not! Delphi performs some trickery and actually does some work behind the scenes. So: When accessing properties, you could either be using variables directly or calling functions behind the scenes! The standard property declaration looks like this: property SomeProperty: Integer read FMyInteger write SetMyInteger; This defines a property "SomeProperty", of type Integer. Note that properties are not actually variables in themselves, just ways of accessing other variables! Thus, the variable actually accessed with "SomeObject.SomeProperty" will be FMyInteger. Now for the interesting bit: the read and write parts say how to access the data. In this case, when the property is read (e.g. "if SomeObject.SomeProperty = 1") the value is taken directly from the variable, as if the code had said "SomeObject.FMyInteger". However, when the property is set, it is not done directly! The code actually calls a SetMyInteger procedure, which would be of the form: procedure SetMyInteger(NewValue: Integer); This gets called instead, as if the code had said "SomeObject.SetMyInteger(23)" instead of "SomeObject.SomeProperty := 23".
Now, the read and write parts can specify direct data access (by putting the variable name) or via procedures/functions (by putting the procedure/function name). To give another example, here's a read-only property that gets its data from a function: property SomeReadOnlyProperty: Boolean read GetMyValue; This property cannot be written to, which safeguards the data nicely :-). The GetMyValue function would be of the form: "function GetMyValue: Boolean;" Whenever the property is accessed, it would call this function to retrieve the value... so the code "if SomeObject.SomeReadOnlyProperty = True then" would get translated into "if SomeObject.GetMyValue = True then" behind the scenes. Important note! The variables (e.g. FMyInteger) and procedures/functions (e.g. GetMyValue, SetMyInteger) are not available to the outside world! They are hidden away using "private" or "protected", so any direct calls would result in errors. This is good, as otherwise the entire purpose of read/write specifiers would be defeated. Private, protected and other such keywords will be explained (much) later. Advantages of Properties You should have noticed why properties are pretty cool, but here's a summary:
They allow you to say how data gets accessed, protecting it They save you from 50,000 "get/set" lines of code, helping readability They allow you to check data integrity before changing the variables
The first one is pretty obvious, really. If you declared your variables publicly they could be changed in any old way. However, you can still allow direct access to your variables if you so desire. Properties allow you to change the behind-the-scenes way of getting or setting data without having to rewrite any code that uses the component! The second point is something that makes you really appreciate Delphi. In other languages (for example C++) you do need to say "someObject.setThisValue(23)" everywhere. This makes your code less readable and just plain sucks! It, in my view, reduces the readability as it detracts from your main intent: you want to change the value, not call the function! Delphi has provided an elegant mechanism to avoid this kind of unnecessary code. The last point is good for efficiency - if you have a graphical component, for example, you want to reduce the drawing as much as possible. This can be done by a set procedure that checks if the old value is different from the new value. Here's an example: procedure TSomeComponent.SetBackgroundColour(NewColour: TColor); begin if NewColour <> FBackgroundColour then begin FBackgroundColour := NewColour; Invalidate; // redraws the component end; end; This means that your component will only redraw itself if it gets a different property value. This technique can be applied elsewhere, with error checks and other such data checking. Methods Methods are very important! These are procedures or functions, and define the behaviour of your objects. They are defined in the usual way, with one-line prototypes in the component and definitions later on. Events
Events get defined by you, and are called whenever you want to notify the programmer of something. You can usually ignore these until you get more experienced with components. They boil down to pointers to class procedures, which means slight complications. Events will be covered later, so don't worry too much about them. Question, Suggestions... If you have any questions or comments to this (huge) article, please post them on the Delphi Programming Forum. Discuss!
Creating Custom Delphi Components - Inside and Out Page 2: New...Component Creating a Component Get the source code here: Line.zip (1Kb) We'll start off at the deep end. We're going to create a simple component, called TLine. It will be a graphical control that will draw a line in one of four directions. It won't do anything fancy, but it will deal with properties, drawing and other useful stuff. How Do We Start? Every component needs a base class. This class is simply the "Big Daddy" object for it, from which the component takes all properties, events and methods. For example, if you were writing a new type of button you might make the base class "TButton". Your new control would have all the TButton's properties (like caption, etc), all the Button's base class's stuff, and so on. There are lots of possible base classes. Here's a small selection: Type of component
Recommended Base Class
Generic, non-visual component
TComponent
Lightweight visual component
TGraphicControl
Visual component that needs focus
TCustomControl
Form-type object
TCustomForm
This is, of course, a small snippet of the possible cases you might need. We're interested in a small visual control, so TGraphicControl is the best base class for us. There's no need for TCustomControl because our component won't need window focus. We can get started now. Go to File->New and select component. You'll be presented with a dialogue box. Fill it out like this:
The only two things you need to fill out are the "Ancestor type" and "Class name" boxes. The rest get filled out automatically. Once you've done that, click the OK button and you get transported to the code editor with a skeleton class written out. First we need to let the compiler know what we'll be using. Each unit (a file, usually containing a class) has a "uses" clause. This lists what other files will be needed to compile the unit. Without this the compiler would have a really hard job so it's up to us to make sure it's correct. Note: The following section about adding Graphics to the uses clause is relevant for Delphi 6 (and possibly Delphi 5). Delphi 4 adds Graphics automatically so if you start a new component and the uses clause has "graphics" in it then you don't need to do the next part. You usually don't notice the "uses" clause as it's filled out with a large number of units by default (such as classes, sysutils, etc.). These units include most of the functionality you require. However, sometimes you have to add your own units (which usually listed in the help files for the appropriate class/procedure/function/type). We'll be needing the type TColor, which represents a colour. If you look this up in the help file you'll see it's within the 'Graphics' unit. Let's add that now before we start. Go to the very top of the file and find the uses part. It will look like this: // <-- name of file without .pas unit Line; interface uses Windows, Messages, SysUtils, Classes, Controls You can see that each unit needed is simply separated by a comma. We'll add Graphics to the uses unit. Make this change: uses Windows, Messages, SysUtils, Classes, Controls, Graphics; //(note added unit) Question, Suggestions...
If you have any questions or comments to this (huge) article, please post them on the Delphi Programming Forum. Discuss!
Creating Custom Delphi Components - Inside and Out Page 3: Adding variables to components Adding Some Variables We need to customise this skeleton code to suit our purposes so let's get busy. The first thing to do is to declare a new type. Change the bit that says: type TLine = class(TGraphicControl) to read: type TLineDirection = (drLeftRight, drUpDown, drTopLeftBottomRight, drTopRightBottomLeft); TLine = class(TGraphicControl) That should be fairly self-explanatory. We declared a new type called TLineDirection, which we can use when drawing to figure out where to draw the line from/to. Now we add in a few variables (called member variables) into the class itself. We need to store:
Line width Line colour Direction
This is where the whole idea of customisation comes in. If you want to, you could add in any variables you think are necessary... you could add in code to draw dotted lines, for example. However, we'll stick with the basics for now. One thing you should have spotted is that we don't actually need to store the line width and colour, as they are properties of the canvas's pen. This is very handy. However, we will need to add in a variable for the direction, as well as get and set functions. Change the private section of the component to look like this: private { Private declarations } FLineDir: TLineDirection; function GetLineWidth: Integer; function GetLineColour: TColor; procedure SetLineWidth(const NewWidth: Integer); procedure SetLineColour(const NewColour: TColor); procedure SetLineDir(const NewDir: TLineDirection); Even though we haven't got variables for the line width and colour, we still need functions to set and retrieve the values from the component's canvas. This is because these three values will be properties of TLine, and properties want you to say how they will read/write, remember? Note we don't need a get function for FLineDir because we can just let the property read its value directly from the variable.
The "F" before LineDir is a bit of notation. It stands for "field", and just means the variable belongs to the class. This makes it a bit easier when writing your component to avoid mixing up local variables with class members. Right, we've declared the functions so I suppose we'd better implement them. Bung this code in after the implementation section (look for the "implementation" keyword in your file and add this immediately after it): function TLine.GetLineWidth: Integer; begin Result := Canvas.Pen.Width; end; function TLine.GetLineColour: TColor; begin Result := Canvas.Pen.Color; end; procedure TLine.SetLineWidth(const NewWidth: Integer); begin if NewWidth <> Canvas.Pen.Width then begin Canvas.Pen.Width := NewWidth; Invalidate; // redraws the component end; end; procedure TLine.SetLineColour(const NewColour: TColor); begin if NewColour <> Canvas.Pen.Color then begin Canvas.Pen.Color := NewColour; Invalidate; end; end; procedure TLine.SetLineDir(const NewDir: TLineDirection); begin if NewDir <> FLineDir then begin FLineDir := NewDir; Invalidate; end; end; The get functions are very self-explanatory. They just nab the values from the Canvas and pass them along. However, the set functions are slightly more complex than just setting the variables. When the set function gets called, we only want to change the appropriate value if necessary. After all, since it's a visual control any unnecessary changes will be apparent to the user (e.g. setting the line direction to the same value again shouldn't cause a redraw). Each of the set functions checks if the new value is different to the current one. If, and only if, it is then we need to change the value and cause a redraw.
Creating Custom Delphi Components - Inside and Out Page 4: Adding propeties to components
Adding Properties The next step is to add properties to the component. We've laid the groundwork so it's simply a matter of bunging them in, like so: published { Published Declarations } property Direction: TLineDirection read FLineDir write SetLineDir; property LineColour: TColor read GetLineColour write SetLineColour; property LineWidth: Integer read GetLineWidth write SetLineWidth; There should be no great surprises in there as you've seen similar property declarations in the previous tutorial part. Now, believe it or not, we've very nearly finished the component! A quick note about "published": any properties in this section will be available in the Object Inspector at designtime. This is, of course, what we want. If you don't want the properties published (if, for example, you only create the component at run-time) then you can place properties in the "public" section. Properties there will be available to outside code, just like published properties, but will not appear in the Object Inspector. If you see "run-time" properties in the help files, it means they're public. The next part is pretty fundamental to TLine - its Paint procedure. We need to draw the component, so it's time to add in some code for that. Since our component has TGraphicControl as a base class it gains a Paint procedure. We just need to modify this to draw our code and we're almost there. Add in this code to the component's "Protected" section: protected { Protected declarations } procedure Paint; override; The override part is a fancy bit, and means our procedure will get called instead of the base class's Paint procedure. We can write the good stuff now, namely the drawing procedure. Add this code in after the implementation part: procedure TLine.Paint; var start: Integer; begin inherited; case FLineDir of drLeftRight: begin start := (Height - Canvas.Pen.Width) div 2; Canvas.MoveTo(0, start); Canvas.LineTo(Width, Start); end; drUpDown: begin start := (Width - Canvas.Pen.Width) div 2; Canvas.MoveTo(start, 0); Canvas.LineTo(start, Height); end; drTopLeftBottomRight: begin Canvas.MoveTo(0, 0); Canvas.LineTo(Width, Height);
end; drTopRightBottomLeft: begin Canvas.MoveTo(Width, 0); Canvas.LineTo(0, Height); end; end; end; The only thing you shouldn't understand is the "inherited" bit. Because the Paint procedure belongs to the base class and we're overriding it, we don't want to miss out on important bits the base class does. The base class here might need to do things like set up the canvas to draw on, get device contexts, allocate resources, or whatever. If we don't let the base class do its thing by calling it via "inherited" we might just find our code blows up. Best not to let that happen, eh? And that, my friend, is enough for a working component. Save the file and go to the Component->Install Component menu, select your file and say OK when it asks if you want to rebuild your library. If all goes well it should tell you that TLine has been registered. You can find it on the Samples palette page and try messing around with it.
Question, Suggestions... If you have any questions or comments to this (huge) article, please post them on the Delphi Programming Forum. Discuss!
Creating Custom Delphi Components - Inside and Out Page 5: On Constructors Constructors and Destructors The TLine component you just created showed the basics of component writing. However, there are two major issues to cover - constructors and destructors. Suppose you use dynamic memory in your component. Without any constructors and destructors this would be very error-prone. You'd end up with code that looked like this: var SomeObject: TSomething; begin SomeObject := TSomething.Create; SomeObject.Init; // yuck! //... use the object now SomeObject.Squish; // yuck! SomeObject.Free; end;
You should be able spot why this would be bad - what if you forget to call Init or Squish? You would end up with an exception or memory leak (bad news) and would look like a fool. Well, luckily, constructors and destructors can help here. Oh, carefully forget to notice that I actually used constructors and destructors in the above example ;-). It's kinda hard in Delphi to avoid them. Constructors Constructors get called whenever you create an object. Their job is to set up the internals of the object (variables, pointers, dynamic memory, etc.) as appropriate. The constructor is used to ensure you have a valid object - it should do no more or less than this. If you find after calling a constructor you still need to call some Init function then you haven't written an appropriate constructor, and should change it. All objects is Delphi have a standard constructor ("Create"), which they get from TObject. This can be used to create the object, like so: SomeObject := TThisClass.Create; where TThisClass is SomeObject's type. You must do this with classes before using them or you will get an exception. When you use the constructor the object gets space allocated for it and can be used. What if you want to change this constructor? Well, you can do this quite easily. Every constructor can get declared like a procedure, but with "constructor" replacing "procedure" in the declaration. Since every object has a "create" constructor available, why not modify this to suit your purposes? Here's an example: type TSomething = class(TObject) public { Public declarations } constructor Create; // etc. end; implementation // and the actual constructor definition constructor TSomething.Create; begin inherited; // do whatever you need (allocate memory, initialise variables, etc.) end; The above is the simplest constructor you might think about. There's only one thing that needs discussing "inherited". Inheritance is a concept in object-oriented design where a class can be a base for other classes. An example might be a "creature" class, which you could use as a base for "cat" and "dog" classes. The cat and dog would get data and behaviour from the "creature" base class, such as moving, having legs, fur, and so on, and would change this to suit their own needs (such as adding "woof" behaviour for dogs). The first class from which others derive is called the "base class" (or "super-class") and the ones that inherit from it are called "derived classes" (or "sub-classes"). Since every class is a sub-class of TObject, they automatically get its properties, methods, events, etc. (a slight exaggeration, as you'll see later). This includes the standard constructors and destructors ("Create" and "Destroy"). Since we have added our own code for the TSomething constructor the other code won't get executed - if you
create a TSomething then TSomething.Create will get called, not TObject.Create. This is bad, as the base class might be doing clever/important things. Using the "inherited" keyword lets you call the base class's same method. This works for any constructor/destructor/procedure/function ("method"). Note that constructors can have any name, and any parameters. You're not just limited to "Create" and "Destroy", so another potential constructor might look like this: type TMyClass = class(TSomething) public constructor InitWithStuff(const x: String); end; implementation constructor TMyClass.InitWithStuff(const x: String); begin inherited Create; // do something with your parameter "x" end; I'll first of all point out the slight change to "inherited". By default, inherited wants to use a method in the base class with the same name and parameters. If there isn't one, you can specify the method manually, as I've done here. You can also pass in parameters - you could, for example, do: inherited SomeProcedure(x,y,z); Now then, the above code makes a sub-class of TSomething, called TMyClass. It now has another constructor called "InitWithStuff". This is NOT available in TSomething, as it has only been introduced in this new class. Note now that TMyClass has two constructors, not just one! You could create a TMyClass like this: someObject := TMyClass.InitWithStuff('hello'); As you'd expect, this uses the constructor "InitWithStuff" we've just added to this new class. However, remember that TMyClass still has the Create constructor. This constructor didn't magically disappear when we created the new class - it's a method of TSomething (from TObject), which means that it's a method of this new derived TMyClass as well. This means it's syntactically correct to create a TMyClass like this: someObject := TMyClass.Create; However, this isn't such a good idea. If an object gives you a constructor you should use it! Because we are bypassing TMyClass's constructor (it really wants us to use InitWithStuff) and are instead using the base class's version (TSomething.Create) we could be creating problems (excuse the bad pun :-p). The object we want might be missing out on some vital work work it needs because we're not using the thing provided. This leads to an important tip: It's usually best to use the same name for constructors for every derived class You can have two constructors (or more) in one class. This means one potential way to get around the problem might be this: type
TMyClass = class(TSomething) public constructor Create; constructor InitWithStuff(const x: String); end; implementation constructor TMyClass.Create; begin raise Exception.Create('You must use InitWithStuff to create a TMyClass'); end; constructor TMyClass.InitWithStuff(const x: String); begin inherited Create; // do whatever stuff you need now end; This solution works, but it's a little silly. It prevents anyone from using Create as a constructor for TMyClass (or any classes that are derived from it and use "inherited") because they'll end up with an exception. However, it's easier just to name your object constructors consistently from base to sub classes (usually you can just stick with "Create", as it's a standard name).
Understanding, Using and Enhancing Delphi VCL Components
Tutorials and articles on using Delphi Visual Component Library (VCL) controls and components more efficiently at design and run time.
TColorButton - button with color properties Full source code of the TColorButton Delphi component, an extension to the standard TButton control, with font color, background color and mouse over color properties. TButton.Color? Have you ever asked yourself a question like: "How can I set the background color of a TButton?" Well, you can't! What's more you cannot change the background color a TButton, TBitBtn and TSpeedButton. The background color of a TButton is controlled by Windows, not by Delphi. TButton is a simple wrapper around the standard Windows button and Windows does not allow it to be colored except by choosing the colors in the Control Panel. Note: to change the default button color system-wide, you need to open the Control Panel; in the Appearances tab of the Display properties applet edit the color of the "3D Objects" item (badly, this will change the color of some other Windows elements). Since Windows insists on doing the background coloring with clBtnFace, the only way to change the background color is to draw the button yourself. In other words, if you want a button where you decide about the color, you will have to make an owner-drawn button component.
TColorButton To overcome the lack of color-related properties of the standard TButton control, I've created the TColorButton custom Delphi component. The TColorButton adds three new properties to the standard TButton:
BackColor - specifies the background color of the button. ForeColor - specifies the color of the button text. Note that this "overrides" the Font.Color property. HoverColor - specifies the color used to paint the button's background when the mouse hovers over the button.
Here's how to set color-related properties of the TColorButton at run time: ColorButton1.BackColor := clOlive; //background ColorButton1.ForeColor := clYelow; //text ColorButton1.HoverColor := clNavy; //mouse over
Installing into a Component palette First, download the component. The TColorButton comes as a single unit file (.pas extension). You'll need to add the component into an existing package. Here's "How to Install Custom Component in Delphi (into Existing Package)" Questions? Comments? Extensions? Exceptions?! That's it. If you find this component practical and if you extend it by adding more properties, please send your source and make it available to other developers. As always if there are any questions or comments please post them on the Delphi Programming Forum.
