2.1 First-generation component models

Components written for first-generation component models are often used in a visual designer that helps developers rapidly construct graphical applications. These component models focus solely on the desktop and not on the enterprise. Such components typically contain graphical controls (also known as widgets), that are manipulated visually. A designer can drag a control to an application window that is under construction, position and resize it, and customize it by changing its properties. A push button may allow its appearance to be customized, for example. A programmer is likely to want custom code to be executed when certain actions occur at runtime, such as a user pressing a button, which is accomplished by adding event handlers to controls.

Components that contain non-graphical controls may also be created for these environments, in some cases significantly extending their functionality. Such an environment may only allow slow-performing scripts to run, making it impractical or impossible to write lower-level code like parts of a network protocol stack. Higher-performing code, written using a traditional programming language, may be packaged as components, whose non-graphical controls are then composed using a visual designer. Provided that all required components are available and can be used as-is, this approach makes it easy to combine components in ever-new assemblies. Creating graphical front-ends to corporate relational databases is a common use of application builders that use first-generation component models (making use of data-aware controls).

Components written for a first-generation component model are, at least in theory, tied to a single environment, and follow only vendor-specific standards.¹ They run in the caller’s operating system process, do not necessarily rely on interfaces and dynamic dispatch, use explicit memory management and are written for the target machine’s native instruction set. Many of the properties enumerated in Chapter 1 do no apply to these components. Components are either distributed as dynamically linked libraries that export vendor-mandated symbols, or are simply statically linked with the applications that use them. Object semantics, if any, are proprietary to the vendor. Examples of environments supporting these component models include early versions of Microsoft’s Visual Basic and Embarcadero’s Delphi.

Despite their simplicity—or perhaps because of it—components written for these environments have done well, both as vehicles for reuse and in the marketplace (Udell 1994).

Footnotes

1. The dearth of published vendor-neutral standards does not preclude a vendor from reverse-engineering the products of a competitor, and offering support for hosting the same kind of components (Udell 1994).