This part ot he tutorial series explains the use of methods and events in Delphi.
In the
last tutorial, we talked about procedures and functions. Today's topic is not so different from the previous. Today we're going to find out what the differences between procedures and methods are. As i've already mentioned, there is a thing in Delphi, called a class. A class itself does nothing at all, in order to use its functionality - we need to have an object of that class. Its the same as if we've defined a class
Student. We have a very abstract understanding about what a student is and what it does. Basically, it does nothing. But if we define an object of the
Student class -
William_T - we already have some actual person that is alive and actually does something. Same goes to objective programming as well. In every form's unit we create, we see the definition of this form's class, but it would be worthless if not for the
var Form1 : TForm1 object. Everything that happens on the form is only thans to this
Form1 object. Every class can have its own variables, functions or procedures. The only difference between classe's procedures and unit's procedures is that they are called differently. Procedures, belonging to the class are called methods and are called a little bit differently that usual functions.
Here's something that we know about functions and procedures in general:
simple functions can be called from any part of the unit by just typing their names.
simple functions can be called from any other unit as long as it has a unit, containing that function, defined in
uses clause.
simple functions can call each other.
object functions (methods) can be called from different class objects or from anywhere in the unit only if they are defined as
public.
methods can be called by typing an object name, followed by a period and the method name (example:
Form1.ShowModal).
methods can be called from any unit by the above rule as long as the calling unit contains a unit, where the required class is defined, in its
uses class.
methods of the same object or a set of same class objects can call each other even if they are not defined in
public clause.
I've used the word
functions to describe both procedures and functions here and the word
methods to also describe both class procedures and functions.
As mentioned above, methods can be accessed via an object of the required class. Let's take a look at the following example:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TForm1 = class(TForm)
private
public
function GetSum(ANr1, ANr2 : integer): integer;
procedure DoOperation;
end;
function CustomGetRnd: integer;
var
Form1: TForm1;
implementation
function CustomGetRnd: integer;
begin
result := Random(100);
end;
function TForm1.GetSum(ANr1, ANr2 : integer): integer;
begin
result := ANr1 + ANr2;
end;
procedure TForm1.DoOperation;
var _tmp : integer;
begin
_tmp := GetSum(CustomGetRnd, CustomGetRnd);
end;
end.
Here we have a function and two methods of a class TForm1. If we called the
Form1.DoOperation method, it would call
CustomGetRnd function two times to get two random numbers and pass it to the summing method
GetSum to get those numbers added to each other. The result would be stored in a variable
_tmp. As you can see, method
DoOperation cal easily call a function in the same unit. Also, methods of the same object can call each other without need to specify an object's name. If you skip the name, Delphi will understand that the method belongs to the context you're calling it from. In our case, we call
GetSum (not
Form1.GetSum) and since we're doing it from a method of
TForm1, Delphi knows where to look the method for.
As you can see, method definitions differ very slightly from simple functions. When you define a method, you just have to place its definition in a public, private or some other clause and the implementation only needs a class name prefixed to the method name. There are no differences.
There are two types of methods in Delphi. First of all, i want to remind you that each and every piece of control you see in Delphi (buttons, text fields etc.) is an object of some class. And almost every visual component in delphi has a second type of methods already defined. The second type of methods are called
events and they are called automatically if something happens. So simple methods are meant to do some actions and events are meant to be triggered automatically when something happens. Let's see how it works. Create a new delphi project and click on the form to select it. Now in property inspector, select the
Events tab. Find an event that says
OnClick and doubleclick in the area next to the title. A method will be defined automatically and the cursor will be placed in that method's implementation to code something. The whole unit should now look like this:
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TForm1 = class(TForm)
procedure FormClick(Sender: TObject);
private
public
end;
var
Form1: TForm1;
implementation
procedure TForm1.FormClick(Sender: TObject);
begin
end;
end.
Change the
FormClick method to look like this:
procedure TForm1.FormClick(Sender: TObject);
var _txt : string;
begin
_txt := 'Hello hello, you''ve just clicked the form!';
Caption := _txt;
end;
Now press
F9 on your keyboard and wait for the application to launch. Click anywhere on the form and see what happens. What happens is that tha title of the form is changed to the value of
_txt. You do not need the
_txt variable to do so, you can assign the text to the
Caption directly, but i've used it just to remind you of basic variable usage. The more often you see it - the better you remember. Now as you see, we have not defined any
Caption variable, so where does it come from? Simple. It is a property (we'll talk about these later) of a form. If you selected the
Properties tab in property inspector, you would see that there is a
Caption field in it. When you change it - the title of the form changes. What we've done here is we've changed the title with the help of the code instead. When you clicked on the form, the
FormClick was automatically called and the title was changed.
Until now we couldn't do any practical coding, because of one simple reason - we didn't have a point to start from. Every procedure or function we've defined was never called and pressing
F9 wouldn't have done anything. But now we know how to create a starting point of our code. That's right - it all begins in events. From now on, if we want to do some real actions - we will drop a button on a form, go to its
Events page in property inspector, doubleclick the
OnClick field and code whatever we need there. So whenever we click the button - the code starts running. Here's another example. To recreate it, paste the code below to a new project's
unit1. Then drop a buttton on the form and doubleclick its
OnClick event in property inspector. You will notice that instead of creating a new method, Delphi takes you to an already existing piece of code. It happened because this piece of code fits the required description and its name is the same as Delphi would name it. Now press
F9.
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
public
function Concat(AStr1, AStr2: string): string;
end;
procedure CloseForm(AForm : TForm);
var
Form1: TForm1;
implementation
procedure CloseForm(AForm : TForm);
begin
AForm.Close;
end;
function TForm1.Concat(AStr1, AStr2: string): string;
begin
result := AStr1 + AStr2;
end;
procedure TForm1.Button1Click(Sender: TObject);
var _txt: string;
begin
_txt := Concat('Hello from ', 'Delphi');
ShowMessage(_txt);
CloseForm(Self);
end;
end.
When you press the button, the
Concat method will be called to "glue" two strings together and the result will be remembered in
_txt variable. Then it will be shown in a message dialog with
ShowMessage procedure. And finally, a global procedure
CloseForm will be called. Now there might be some difficulty to understand the
CloseForm procedure so let's have a look at it. As you can see, this procedure accepts one argument:
AForm. Its type is
TForm. This is exaclty the same as with integers, strings etc. Instead, we require a more complex parameter than the mentioned: we require a form's object. You could also notice that the parameter does not have a type of
TForm1, instead it is has a type of
TForm. This is difficult to explain just now, we'll be talking about it when we reach the Object Orientated Programming part of the tutorials series. For now, let's just say it is correct and not bother ourselves why. The third thing we need to clarify, is the call itself. In it you can see some
Self variable. When you use
Self, Delphi replaces it with the object it was called from. For example, we do not need to specify the object when we call its method from the same object. But what if we need to pass an object from itself? Sure, delphi understands that we are in that object and that we're calling
CloseForm from that object, but we still need to pass it to the procedure. That's where
Self comes in. You can also use the
Form1 variable instead, but in some situations there could be many objects and you will not know in which you are yourself, so you'll only be able to use
Self. The
CloseForm procedure itself is pretty simple. It calls the passed object's
Close method. This method is implemented in all forms and what it does is ... you guessed - closes the form. Alternatively, you could have written
Self.Close; or just
Close; instead of that
CloseForm call, but, as i've said before - the more you see - the more you remember :) One more thing to notice is that when you close your main form (the one you created first) - your program is shutdown automatically. So by closing
Form1 we also exit our program.
So that's basically it for this tutorial. In the next tutorial, we'll be talking about conditional statements. So go ahead and
click here if you're ready.