Published Members Published members have the same visibility as public members. The difference is that runtime type information
(RTTI) is generated for published members. RTTI allows an application to query the fields and properties of an object
dynamically and to locate its methods. RTTI is used to access the values of properties when saving and loading
form files, to display properties in the Object Inspector, and to associate specific methods (called event handlers)
with specific properties (called events).
Published properties are restricted to certain data types. Ordinal, string, class, interface, variant, and method-pointer
types can be published. So can set types, provided the upper and lower bounds of the base type have ordinal values
between 0 and 31. (In other words, the set must fit in a byte, word, or double word.) Any real type except Real48
can be published. Properties of an array type (as distinct from array properties, discussed below) cannot be
published.
Some properties, although publishable, are not fully supported by the streaming system. These include properties
of record types, array properties of all publishable types, and properties of enumerated types that include anonymous
values. If you publish a property of this kind, the Object Inspector won't display it correctly, nor will the property's
value be preserved when objects are streamed to disk.
All methods are publishable, but a class cannot publish two or more overloaded methods with the same name. Fields
can be published only if they are of a class or interface type.
A class cannot have published members unless it is compiled in the
{$M+}
state or descends from a class compiled
in the
{$M+}
state. Most classes with published members derive from TPersistent, which is compiled in the
{$M
+}
state, so it is seldom necessary to use the
$M
directive.
Note: Identifiers that contain Unicode characters are not allowed in published sections of classes, or in types used
by published members.
