The Visual Component Library did not merely wrap Win32 controls — it placed every visual and non-visual object inside a single ownership hierarchy that the compiler, the designer and the runtime all understood at once.
A Hierarchy the Compiler Could Read
Earlier widget toolkits — Motif, the Windows 3.x SDK, even the Object Windows Library that shipped before Delphi — treated the screen widget and the application's data logic as separate concerns stitched together by callbacks or message maps. The programmer held that relationship in their head. The VCL's founding insight was that a component should carry its own metadata, its own persistence and its own design-time behaviour as inseparable parts of its type definition.
The architecture rested on TComponent, the base class from which every VCL object descended. TComponent introduced ownership: any component could own child components, and the framework guaranteed their lifetime without manual memory management by the developer. From TComponent the hierarchy split: TControl extended it with visual presence, painting and mouse handling, while non-visual components — timers, database connections, dialogue controllers — stayed at the TComponent level and appeared on the form as icons at design time rather than as screen widgets.
What made this distinct was the published property. A property declared in the published section of a class caused the Object Pascal compiler ↗ to emit RTTI ↗ — run-time type information — describing the property's name, type and accessor. That RTTI was not a documentation artefact or a debug annotation; it was the mechanism by which the form designer read and wrote every value in the Object Inspector, and by which the streaming system serialised the component tree into the DFM file at save time and reconstituted it at load time. Compiler, designer and runtime all consumed the same metadata from the same binary.
Designer, File and Runtime in Agreement
The DFM file — the Delphi Form file stored alongside each Pascal unit — recorded the component tree as a hierarchy of names, types and property values. Because the streaming system relied on RTTI rather than hand-written loaders, any third-party component that correctly declared its published properties became a first-class citizen in the designer: draggable, inspectable, persistable, serialisable, without any privileged access to IDE internals. Ray Konopka's work on custom component authorship, widely circulated through The Delphi Magazine and his own writing, demonstrated in practice how deep that extensibility ran.
The VCL's depth is the point: a form arrives with several generations of ancestor behaviour already linked into it.
A parts store rather than a code library, but the same premise — take a standard piece off the shelf instead of making one.
Photo: Charlie Merrow / Pexels
The consequence for the developer's workflow was structural. The component was the unit of work: not a function, not a widget, not a data record, but a self-describing object that carried behaviour, state and visual representation together. Dropping a component onto a form generated a field declaration in the Pascal type block and a streaming entry in the DFM simultaneously. Deleting it removed both. The source file and the binary representation could not diverge, because the same compiler pass validated both.
This stood in direct contrast to the resource-file approach common in Windows development at the time, where a .RC file described a dialogue's layout and a separate .C or .CPP file contained the handlers, with no shared type system enforcing their agreement. Breaking that agreement was a runtime error that the compiler could not catch. The VCL narrowed the gap by expressing form layout in the same type system as the logic, so that most mismatches surfaced at compile time or as load-time errors rather than going unnoticed.
The model's durability is measurable: the BPL package format — Delphi's specialised DLL variant for distributing compiled components — carried VCL components into Embarcadero's FireMonkey era and beyond, and the published-property/RTTI contract that Delphi 1 established in 1995 remains the load-bearing structure of modern RAD Studio's designer today. Component vendors from DevExpress to TMS Software built catalogues containing hundreds of components each on precisely this contract, confident that the IDE would treat their types exactly as it treated Borland's own.
More in Delphi