VCL is an acronym for the Visual Component Library, a set of visual components for rapid development of Windows applications in the Delphi language. VCL contains a wide variety of visual, non-visual, and utility classes for tasks such as Windows application building, web applications, database applications, and console applications. All classes descend from TObject. TObject introduces methods that implement fundamental behavior like construction, destruction, and message handling.

VCL.Net contains only a subset of the full functionality available in VCL for Win32. The .NET Framework was architected to accommodate any .NET-compliant language. In many cases, Delphi source code that operates on Win32 VCL classes and functions recompiles with minimal changes on .NET. In some cases, the code recompiles with no changes at all. Since VCL.NET is a large subset of VCL, it supports many of the existing VCL classes. However, source code that calls directly to the Win32 API requires source code changes.

Components are a subset of the component library that descend from the class TComponent. You can place components on a form or data module and manipulate them at designtime. Using the Object Inspector, you can assign property values without writing code. Most components are either visual or nonvisual, depending on whether they are visible at runtime. Some components appear on the Component Palette.

Visual components, such as TForm and TSpeedButton, are called controls and descend from TControl. Controls are used in GUI applications, and appear to the user at runtime. TControl provides properties that specify the visual attributes of controls, such as their height and width.

Nonvisual components are used for a variety of tasks. For example, if you are writing an application that connects to a database, you can place a TDataSource component on a form to connect a control and a dataset used by the control. This connection is not visible to the user, so TDataSource is nonvisual. At designtime, nonvisual components are represented by an icon. This allows you to manipulate their properties and events just as you would a visual control.

Classes that are not components (that is, classes that descend from TObject but not TComponent) are also used for a variety of tasks. Typically, these classes are used for accessing system objects (such as a file or the clipboard) or for transient tasks (such as storing data in a list). You cannot create instances of these classes at designtime, although they are sometimes created by the components that you add in the Form Designer.

Many components are provided in the IDE on the Component Palette. You select components from the Component Palette and place them onto a form or data module. You design the user interface of an application by arranging the visual components such as buttons and list boxes on a form. You can also place nonvisual components, such as data access components, on either a form or a data module. At first, Delphi’s components appear to be just like any other classes. But there are differences between components in Delphi and the standard class hierarchies that many programmers work with. Some differences are:

• All Delphi components descend from TComponent.
• Components are most often used as is. They are changed through their properties, rather than serving as base classes to be subclassed to add or change functionality. When a component is inherited, it is usually to add specific code to existing event handling member functions.
• Components can only be allocated on the heap, not on the stack.
• Properties of components contain runtime type information.
• Components can be added to the Component Palette in the IDE and manipulated on a form.

Components often achieve a better degree of encapsulation than is usually found in standard classes. For example, consider a dialog box containing a button. In a Windows program developed using VCL components, when a user clicks the button, the system generates a WM_LBUTTONDOWN message. The program must catch this message (typically in a switch statement, a message map, or a response table) and send it to a routine that will execute in response to the message. Most Windows messages (VCL applications) are handled by Delphi components. When you want to respond to a message or system event, you only need to provide an event handler.

Almost all the code you write is executed, directly or indirectly, in response to events. An event is a special kind of property that represents a runtime occurrence, often a user action. The code that responds directly to an event, called an event handler, is a Delphi procedure. 

The Events page of the Object Inspector displays all events defined for a given component. Double-clicking an event in the Object Inspector generates a skeleton event handling procedure, which you can fill in with code to respond to that event. Not all components have events defined for them. 

Some components have a default event, which is the event the component most commonly needs to handle. For example, the default event for a button is OnClick. Double-clicking on a component with a default event in the Form Designer will generate a skeleton event handling procedure for the default event.  

You can reuse code by writing event handlers that respond to more than one event. For example, many applications provide speed buttons that are equivalent to drop down menu commands. When a button performs the same action as a menu command, you can write a single event handler and then assign it to the OnClick event for both the button and the menu item by setting the event handler in the Object Inspector for both the events you want to respond to.  

This is the simplest way to reuse event handlers. However, action lists, and in the VCL, action bands, provide powerful tools for centrally organizing the code that responds to user commands. Action lists can be used in cross-platform applications; action bands cannot.

To set published properties at design time, you can use the Object Inspector and, in some cases, property editors. To set properties at runtime, assign their values in your application source code. 

When you select a component on a form at design time, the Object Inspector displays its published properties and, when appropriate, allows you to edit them. 

When more than one component is selected, the Object Inspector displays all properties—except Name—that are shared by the selected components. If the value for a shared property differs among the selected components, the Object Inspector displays either the default value or the value from the first component selected. When you change a shared property, the change applies to all selected components.  

Changing code-related properties, such as the name of an event handler, in the Object Inspector automatically changes the corresponding source code. In addition, changes to the source code, such as renaming an event handler method in a form class declaration, are immediately reflected in the Object Inspector.

Building a VCL Forms Application 

Building a VCL Forms "Hello world" Application 

Organizing Actions for Toolbars and Menus