Search:
All Any

Part of mariaus.info network Subscribe via RSS
Follow on twitter Request a tutorial
Visitor request: Make a single object in a photo colored
Create an automated reusable software box model
Create a supernova in Photoshop
Advanced moving through space animation
Business card # 2
Photography and art inspiration # 3
Photography and art inspiration # 2
Photography and art inspiration # 1
Photography and art inspiration # 4
Go to first pageAdd to favorites (this)Contact page ownerRequest a tutorialSubscribe to the Tip Kit news
Request a tutorial
Introduction to Delphi, Part 6 - Methods and Events

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
    { Private declarations }
  public
    function GetSum(ANr1, ANr2 : integer): integer;
    procedure DoOperation;
  end;

  function CustomGetRnd: integer;

var
  Form1: TForm1;

implementation

{$R *.dfm}

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
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

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
    { Private declarations }
  public
    function Concat(AStr1, AStr2: string): string;
  end;

  procedure CloseForm(AForm : TForm);


var
  Form1: TForm1;

implementation

{$R *.dfm}

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.

Article written by: Marius S.
This article is an intellectual property of its respective author. All images, used here are property of tip-kit.com if not stated otherwise.
Share this article
Digg del.icio.us Facebook Furl Google Reddit Slashdot StumbleUpon Technorati
How easy was it to understand? Was it useful?










Leave a reply
Your name:

Message:

Confirmation code
Please enter the above code:
Ken says:
I am having difficulty finding an example of a DLL. There are lots of examples but it would seem that everyone is trying to be too clever or I am trying to read too much into it.
I want to be able to pass a string parameter to an external function or procedure in a DLL and for that procedure or function in the DLL to lookup up some information in a table and return that information (string) back to the calling program.
Can you give me an example
Thanks
Ken
2012-01-29 21:57:37 (GMT)
Copyright © 2009 Tip-Kit.Com | Valid XHTML 1.0 | Powered By Isis | RSS