Typecasts can be used to coerce a type declared one way to be treated as some other type that descends from it. For instance, in the following code a typecast is used to enable an object declared as type TPersistent to be treated as a TStringList:
procedure TForm1.Button2Click(Sender: TObject); var F: TPersistent; L: TStringList; begin L := TStringList(F); end;
You perform a typecast by stating the name of the type that you want to declare and then placing the object that you want to typecast in parenthesis. The compiler is smart enough to know that this is a typecast, not a function call. The user can often make the same deduction simply by seeing that TStringList begins with the telltale T, which stands for "type." That particular initial consonant gives away the fact that TStringList is a type, not a function.
The as and is Operators and the Sender Parameter
Typecasts are an essential part of working with a language that supports polymorphism. In many Kylix programs, the IDE generates event handlers that are passed objects declared to be one type but that are actually descendants of the type passed. The classic example of this is the Sender parameter, seen in many event handlers:
procedure TForm1.Button1Click(Sender: TObject); begin end;
The Button1Click method in a typical Delphi application is called when the user clicks on Button1. In that case, the Sender parameter really contains a TButton object. Flexibility is gained, however, if you declare the parameter as a TObject. The declaration enables you to pass any Pascal object to this method, not just a TButton.
All Object Pascal classes must descend from TObject or one of its descendants. Even if you declare an object to have no ancestor, the Pascal compiler automatically descends the class from TObject. You simply can't declare an Object Pascal class that does not descend from TObject or one of its descendants. As a result of this rule, it is legal to pass any object in the Sender parameter of the Button1Click method. This extraordinary flexibility is possible because all these objects, by definition, descend from TObject.
Let's look at a practical example of how declaring the Button1Click method to take a TObject might be useful in a real program. Imagine that a message handler that you want to respond to clicks on not only a TButton, but also a TBitButton and TSpeedButton. The previous declaration could work with any of those types because they are all descendants of TObject. More particularly, the magic of polymorphism grants TButton, TBitButton, or TSpeedButton the capability to masquerade as a lowly TObject.
Never forget the hierarchical nature of polymorphism: The king can masquerade as a pawn, but a pawn cannot pretend to be a king. A TButton can go disguised as a TObject, but a TObject cannot put on airs and pretend to be a TButton.
Here is how you can get at the object passed in the Sender parameter:
procedure TForm1.Button1Click(Sender: TObject); var Button: TButton; begin Button := TButton(Sender); end;
As you can see, you need do nothing more than perform a simple typecast, and the Sender object is uncloaked and its true nature as an instance of TButton is revealed. In this case, the typecast again plays the role of the truth-teller, stripping off the object's disguise.
But doesn't trouble lurk amid the players of this game of cat and mouse? What would happen if the truth-teller were wrong? If you typecast a Sender object as a TButton, but it was really a TBitButton, TSpeedButton, TPanel, or something else passed unexpectedly, your typecast would be allowed at compile time, but an exception would be raised at runtime. Here is what you can do in such cases:
procedure TForm1.Button1Click(Sender: TObject); var Button: TButton; begin if Sender is TButton then Button := TButton(Sender); end;
This code uses the is operator to test whether Sender is of type TButton. If it is, the if statement evaluates to true and the call succeeds. If it is not, the second line attempting the typecast is never called.
There is another way to perform a typecast that is perhaps a bit more modern than the way I have shown you so far:
procedure TForm1.Button1Click(Sender: TObject); var Button: TButton; begin Button := Sender as TButton; end;
This code yields that same result as writing Button := TButton(Sender). The difference is that the code will raise an exception if Sender is not of type TButton. The as operator is a prophylactic ensuring that the typecast will not be made if it is not valid. I also find the code easy to read because it cannot be mistaken as a method call, per the discussion earlier in this section. On the other hand, the code might take longer to execute than the other kind of typecast because it is adding the overhead of type checking. (An actual ruling on the performance of the two forms of typecasts will have to be left to someone else because I am not an expert in this kind of performance issue. But certainly the additional type checking must add at least some overhead to your program.)
The as operator is most typically used in statements that look like this:
procedure TForm1.Button2Click(Sender: TObject); var F: TPersistent; L: TStringList; begin (F as TStringList).Add(`Sam'); end;
Here you can see the way parentheses have been added to give precedence to the as operator and ensure that the compiler can make proper sense of your statement.
Hopefully you now understand the basics of how typecasts work in an Object Pascal program. If you still feel that you could use more enlightenment on this issue, just be patientthe subject will come up numerous times throughout the course of this book.