Run-Time Type Information In Delphi - Can It Do Anything For You?

To get the type name of an appropriate type at run-time we can use something like:

TTypeInfo(TypeInfo(Integer)^).Name

The last TTypeInfo field, TypeData, is commented out because the Name field (a string holding the type name) is not what it seems. It is implemented as an old-style Pascal short string, but for space efficiency only takes up as many bytes as are required for the type name, rather than a fixed number (which would leave several unused characters). Therefore the position of the TypeData field is variable.

If we want to get access to the TypeData field we have to fiddle around somewhat, setting up a pointer to the relevant position in the record after using the length of Name to identify where it is. The TypInfo unit provides a routine to do this as we will see later.

The TTypeData record is where things get interesting/messy (delete as appropriate). It is a large variant record with different fields being used depending on the value of the TTypeInfo.Kind field. Let’s look at a simplified view of it.

TTypeData = packed record
  case TTypeKind of
    tkUnknown, tkLString, tkWString, tkVariant: ();
    tkInteger, tkChar, tkEnumeration, tkSet, tkWChar (...):
    tkFloat: (FloatType: TFloatType);
    tkString: (MaxLength: Byte);
    tkClass: (...);
    tkMethod: (...);
    tkInterface: (...);
    tkInt64: (...);
  end;

In the case of a long or wide string or variant there is no additional type information recorded. For a floating point type, a value from the TFloatType appears that specifies what variety it is.

TFloatType = (ftSingle, ftDouble, ftExtended, ftComp, ftCurr);

There are two thing to notice here. Firstly, the ftCurr symbol was new in Delphi 2 to denote the Currency type.

In the case of a short string, the maximum length is recorded, and for ordinal types, class types, method types and interface types, more information is stored.

...
tkInteger, tkChar, tkEnumeration, tkSet, tkWChar: (
  OrdType: TOrdType;
  case TTypeKind of
    tkInteger, tkChar, tkEnumeration, tkWChar: (
      MinValue: Longint;
      MaxValue: Longint;
      case TTypeKind of
        tkInteger, tkChar, tkWChar: ();
        tkEnumeration: (
          BaseType: PTypeInfo;
          NameList: ShortString));
        tkSet: (
          CompType: PPTypeInfo));
...

All ordinal types have a field OrdType of type TOrdType which says how many bytes are required and whether signed values are supported.

TOrdType = (otSByte, otUByte, otSWord, otUWord, otSLong);

If the type is not a set, the minimum and maximum values are available in terms of Longints and if it is an enumerated type you can gain access to all the enumerated type value names. There is also a field called BaseType which presumably is meant to point to the RTTI table for the enumerated type used as a basis for this one, but I have been unable to get it to point to anything other than the same type’s RTTI.

If the type is a set, you can get to the RTTI table for the set’s base type - the ordinal type whose values can be in a set of this type. Note that the BaseType field for an enumerated type mentioned just above and the CompType field for a set are PTypeInfo’s in Delphi 1 and 2 (pointers to TTypeInfo records) but are defined as PPTypeInfo’s in Delphi 3 onwards (pointers to PTypeInfo record pointers). This should, in theory require conditional compilation but in fact you can forget about the extra level of indirection in Delphi 3+. It has been the case since Delphi 2 came out that if a de-reference operation was required (i.e. a caret, ^, sign was needed) you could dispense with it if there would be no ambiguity as to what was intended.

...
tkClass: (
  ClassType: TClass;
  ParentInfo: PTypeInfo;
  PropCount: Smallint;
  UnitName: ShortString
  {PropData: TPropData});
...

RTTI for a class type includes a class reference, a pointer to the ancestor class’s RTTI table (again defined as PTypeInfo or PPTypeInfo depending on which version), the number of published properties and the name of the defining unit. Again, this name is only as long as it needs to be, hence the commented field that follows. In addition, there is a TPropData record that follows containing data about all the published properties.

TPropData = packed record
  PropCount: Word;
  PropList: record end;
  {PropList: array[1..PropCount] of TPropInfo}
end;

This time the commented out field at the end can be accessed because it is not preceded by an indeterminately long string. However because this PropList field is supposed to be a variably sized array, its declaration is commented and substituted with an empty record. PropCount dictates how many TPropInfo records there are, and each TPropInfo record contains all the characteristics of a published property.

TPropInfo = packed record
  PropType: PTypeInfo;
  GetProc: Pointer;
  SetProc: Pointer;
  StoredProc: Pointer;
  Index: Integer;
  Default: Longint;
  NameIndex: Smallint;
  Name: ShortString;
end;

We have a pointer to the RTTI table for the property’s type, a pointer to the property reader and property writer methods. Additionally there is a reference to the method, field or value that is used to determine whether to store the property value in the form file (specified with the stored directive), the property index (specified with the index directive), a default value (specified by the default directive, which is also used to dictate whether the property gets stored in the form file) and its name.

...
tkMethod: (
  MethodKind: TMethodKind;
  ParamCount: Byte;
  ParamList: array[0..1023] of Char
  {ParamList: array[1..ParamCount] of
    record
      Flags: TParamFlags;
      ParamName: ShortString;
      TypeName: ShortString;
    end;
  ResultType: ShortString});
...
 
TMethodKind = (mkProcedure, mkFunction);
TParamFlags = set of (pfVar, pfConst, pfArray);

Information about published method is also quite full. We can find out if the method is a procedure or function, and how many parameters it has. Delphi 3 added new values to the TMethodKind type (mkSafeProcedure and mkSafeFunction) to represent routines compiled with the new safecall directive as used in dual interface declarations and implementations. Delphi 4 added several more: mkConstructor, mkDestructor, mkClassProcedure, and mkClassFunction. ParamCount specifies also how many parameter description records (the commented out record below) exist, and each one of those has an indication of whether the parameter has a var or const prefix, if it is an array, and also what the parameter’s name and type name are. Again, Delphi 3 extended the TParamFlags type with pfAddress, pfReference and pfOut for the new parameter types supported in interfaces.

The TTypeData record has a lot of useful stuff in, but of course with all these non-standard strings dotted here and there, accessing the various constituent records proves a bit tricky. There are a number of routines in the TypInfo unit to help us out, as explained below.

What Can We Do With RTTI?

The routines available in the TypInfo unit are much the same in the three current versions of Delphi, although in some cases where strings are returned they differ. In Delphi 1, pointers to strings are sometimes returned, but in Delphi 2 and 3 the strings themselves are always returned.

The routines tend to take either a PTypeInfo or PPropInfo pointer - a pointer to an RTTI table or to a property information record as described above.

Remember that a PTypeInfo pointer can be obtained both from the TypeInfo function for most types and from the ClassInfo class method for object references and class references. It’s interesting that to make things simple, the TTypeData record for a class type also has ClassType field that points back to the class reference.

We can gain easy access to the TTypeData record using GetTypeData which returns a pointer to it:

function GetTypeData(TypeInfo: PTypeInfo): PTypeData;

GetTypeData(TypeInfo(TForm1))^.UnitName

To be more generic, bearing in mind the form's class name may have changed, we could use:

GetTypeData(Application.MainForm.ClassInfo)^.UnitName

Since all of the TypInfo routines that operate on properties want a PPropInfo, there are several ways of getting one. GetPropInfo gets a TPropInfo record for a named property. GetPropInfos gets TPropInfos for all published properties in the class and its ancestors, and puts them in a TPropList array. Lastly, GetPropList will get all the properties whose types match the values in the set parameter TypeKinds and return how many it found. If you pass tkProperties as this parameter, it acts much the same as GetPropList (although GetPropList does not return how many properties were found - you have to use TTypeData.PropCount instead).

const
  tkAny = [Low(TTypeKind)..High(TTypeKind)];
  tkMethods = [tkMethod];
  tkProperties = tkAny - tkMethods - [tkUnknown];
 
PPropList = ^TPropList;
TPropList = array[0..16379] of PPropInfo;
 
function GetPropInfo(TypeInfo: PTypeInfo;
  const PropName: string): PPropInfo;
procedure GetPropInfos(TypeInfo: PTypeInfo; PropList: PPropList);
function GetPropList(TypeInfo: PTypeInfo; TypeKinds: TTypeKinds;
  PropList: PPropList): Integer;

For example, to get the names of all form properties in a listbox called ListBox1, you could write:

procedure TForm1.FormCreate(Sender: TObject);
var
  Count, Loop: Integer;
  List: TPropList;
begin
  Count := GetPropList(TypeInfo(TForm1), tkAny, @List);
  Listbox1.Items.BeginUpdate;
  for Loop := 0 to Pred(Count) do
    Listbox1.Items.Add(List[Loop]^.Name);
  Listbox1.Items.EndUpdate;
end;

or perhaps like the following which would only take as much memory as is required:

procedure TForm1.FormCreate(Sender: TObject);
var
  Count, Loop: Integer;
  List: PPropList;
begin
  Count := GetPropList(TypeInfo(TForm1), tkAny, nil);
  GetMem(List, Count * SizeOf(PPropInfo));
  try
    GetPropList(TypeInfo(TForm1), tkAny, List);
    Listbox1.Items.BeginUpdate;
    for Loop := 0 to Pred(Count) do
      Listbox1.Items.Add(List^[Loop]^.Name);
    Listbox1.Items.EndUpdate;
  finally
    FreeMem(List, Count * SizeOf(PPropInfo))
  end;
end;

Reading and writing arbitrary properties

There are five pairs of routines (four in Delphi 1) for reading and writing property values of a given name (a sixth was added in Delphi 4):

The Get/SetOrdProp routines both take an object reference and a pointer to a property information record and they either take or return a Longint. A four-byte Longint is big enough to represent any Pascal ordinal value and also any object reference and so you use a typecast to translate between your value of interest and the Longint.

function GetOrdProp(Instance: TObject; PropInfo: PPropInfo): Longint;
procedure SetOrdProp(Instance: TObject;
  PropInfo: PPropInfo; Value: Longint);

The other routines are laid out in a similar way, but take or return a value of an appropriate type.

These routines are used by the VCL streaming mechanics to read and write form files. Once a property value is read from a form file, information is looked up (a TPropInfo record) and its type category is identified (TTypeKind). Then the relevant property writing routine is invoked to set the property value with the data read in from the form file.

Common properties with no common ancestor

You can often come up against a requirement to set a property in many components where there is no common ancestor that defines this property. Let’s look at an example or two to emphasise the problem and see how RTTI can offer us a solution.

Example 1 - the Enabled property

Consider this scenario. You have a form with a number of controls on that all need to be disabled by having their Enabled property set to False. The controls might be a button, an edit control and a check box, but then again may be of some other types. You could implement a routine called DisableThem as shown below that disables any controls.

procedure DisableThem(Comps: array of TControl);
var
  Loop: Integer;
begin
  for Loop := Low(Comps) to High(Comps) do
    Comps[Loop].Enabled := False;
end;
...
DisableThem([Button1, Edit1, Checkbox1]);

Now consider that you also need to disable some menu items, which also have an Enabled property. The problem here is that the TMenuItem class adds Enabled as a new property of its own - TMenuItem is derived from TComponent that does not have an Enabled property. On the other hand, the TButton, TEdit and TCheckBox class all inherit the Enabled property from their common ancestor type TControl.

So the Enabled property of the TMenuItem and that of all the other classes are actually different properties - they just have the same names. This means we have to use a different coding approach.

procedure DisableThem(Comps: array of TComponent);
var
  Loop: Integer;
begin
  for Loop := Low(Comps) to High(Comps) do
    if Comps[Loop] is TMenuItem then
      TMenuItem(Comps[Loop]).Enabled := False
    else
      TControl(Comps[Loop]).Enabled := False;
end;
...
DisableThem([Button1, Edit1, Checkbox1, Menu1]);

If we need to address other components with unique Enabled properties, this code will lengthen. A possibly better approach that takes advantage of the SetOrdProp routine from the TypInfo unit follows.

procedure DisableThem(Comps: array of TComponent);
var
  Loop: Integer;
  PropInfo: PPropInfo;
begin
  for Loop := Low(Comps) to High(Comps) do
  begin
    { Get info record for Enabled property }
    PropInfo := GetPropInfo(Comps[Loop].ClassInfo, 'Enabled');
    { If property exists, set value to False }
    if Assigned(PropInfo) then
      SetOrdProp(Comps[Loop], PropInfo, Longint(False));
  end;
end;

The projects Generic.Dpr and Genric2.Dpr that accompany this paper shows this same idea in a couple of ways, one more generic than the other.

uses
  TypInfo;
...
procedure SetDataSource(Comps: array of TControl; DS: TDataSource);
var
  Loop: Integer;
  PropInfo: PPropInfo;
begin
  for Loop := Low(Comps) to High(Comps) do
  begin
    { Get info record for DataSource property }
    PropInfo := GetPropInfo(Comps[Loop].ClassInfo, 'DataSource');
    { If property exists, set value to DS }
    if Assigned(PropInfo) then
      SetOrdProp(Comps[Loop], PropInfo, Longint(DS));
  end;
end;
...
Table1.Open;
SetDataSource([DBEdit1, DBText1, DBNavigator1], DataSource1);

TDayOfWeek = (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);

It is possible to start with a string ‘Tuesday’ and get a TDayOfWeek value Tuesday out. It is also possible to do the reverse. The two routines GetEnumName and GetEnumValue do this and to work with them requires a typecast between any enumerated value and an Integer.

function GetEnumName(TypeInfo: PTypeInfo; Value: Integer): string;
function GetEnumValue(TypeInfo: PTypeInfo; const Name: string): Integer;

TFormBorderStyle = (bsNone, bsSingle, bsSizeable, bsDialog);

uses
  TypInfo;
...
{ Write current border style on form caption }
Caption := GetEnumName(TypeInfo(TFormBorderStyle),
Ord(BorderStyle)){$ifdef Windows}^{$endif};
...
{ Change current border style to single-line }
BorderStyle := TFormBorderStyle(
GetEnumValue(TypeInfo(TFormBorderStyle), 'bsSingle'));

You can find code like this in the projects EnumEg.Dpr and EnumEg2.Dpr that accompany this paper.

As mentioned just above, it is still down to the developer to manually set the properties to their default values in the constructor. This can be a bit of a chore to do, particularly if there are several of them. To simplify the task we can use the RTTI information, looping through all the published properties that might have a default value and apply it. The code shown here (and available to test out in the PropEg.Pas component unit and RttiUnit.Pas utility unit) is based on code from Secrets Of Delphi 2 by Ray Lischner, published by The Waite Group.

...
constructor TDefaultPropertyExample.Create(AOwner: TComponent);
begin
  inherited;
  { This is the traditional way of setting }
  { default property values - assign the }
  { value required to each of the underlying }
  { data fields one at a time, e.g. }
  { FProperty1 := 10; }
  { FProperty1 := 20; }
  { FProperty1 := 30; }
 
  { But here is a neater way as shown in Secrets of Delphi 2 }
  { use the RTTI to do it all automatically. The code }
  { is then the same for each component constructor }
  SetDefaults(Self)
end;
 
const
  NoDefault = $80000000;
  tkPropsWithDefault = [tkInteger, tkChar, tkSet, tkEnumeration];
 
procedure SetDefaults(Obj: TObject);
var
  PropInfos: PPropList;
  Count, Loop: Integer;
begin
  { Find out how many properties we'll be considering }
  Count := GetPropList(Obj.ClassInfo, tkPropsWithDefault, nil);
  { Allocate memory to hold their RTTI data }
  GetMem(PropInfos, Count * SizeOf(PPropInfo));
  try
    { Get hold of the property list in our new buffer }
    GetPropList(Obj.ClassInfo, tkPropsWithDefault, PropInfos);
    { Loop through all the selected properties }
    for Loop := 0 to Count - 1 do
      with PropInfos^[Loop]^ do
        { If there is supposed to be a default value... }
        if Default <> NoDefault then
          { ...then jolly well set it }
          SetOrdProp(Obj, PropInfos^[Loop], Default)
  finally
    FreeMem(PropInfos, Count * SizeOf(PPropInfo));
  end;
end;

The RTTIUnit.pas unit that accompanies this paper has a routine called CopyObject defined in it. CopyObject takes two object references - a source object and a target object. It iterates through all the published properties in the source object and attempts to set the value of the same property in the target. If the property doesn’t exist in the target then it skips onto the next one.

CopyObject(BitBtn1, Button1);
CopyObject(BitBtn1, Edit1);
Button1.Left := BitBtn1.Left + BitBtn1.Width + 2;
Edit1.Left := Button1.Left + Button1.Width + 2

The code is a bit too lengthy to list here but isn’t really that far removed from the default property setting code above. Refer to the unit for the source. Also, the sample project CopyEg.Dpr supplied with this paper shows an example of the function in use.