• Juarez Rudsatz (81/81) Dec 05 2001 The Delphi Event approach has its drawbacks.
• Pavel Minayev (9/14) Dec 05 2001 IMHO the big problem here is that unlimited-depth cascading

"Juarez Rudsatz" <juarez mpsinf.com.br> writes:

The Delphi Event approach has its drawbacks.
The major one is the dificulty of making cascating events :

type
    TEvent = procedure of object;

    TMyObj = class(TAnyClass)
        private
            FOnEvent : TEventProc.
        published
            property Event : TEvent read FOnEvent write FOnEvent;
    end;
var MyObj : TMyObj;
...

procedure ProcEvent;
begin
...
end;
...
begin
    MyObj.Event := ProcEvent.
end.

Until now nothing new. But try assign a new event for any object without
droping the last.
Think in another object TAnotherObj wich know TMyObj and need add a new
action when event is fired.
Always the programmer must code the cascating :

type
    TAnotherObj = class(TAnyoneObj)
        private
           FEventCasc : TEvent
...

procedure TAnotherObj.AssignEvent(Obj : TMyObj).
begin
    FEventCasc := Obj.OnEvent;
    Obj.OnEvent := Self.FireEvent;
end;

procedure TAnotherObj.FireEvent;
begin
    if FEventCasc <> nil then
      FEvent; // Fire the old event
     ...
end;

The problem is the endless repetition of this problem in all Delphi
components and framewoks.
Sometime can we think in a better solution for this problem.
If you are thinking in adding event like mecanism for D is important to
think in event cascating too.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:9uidvf$2212$1 digitaldaemon.com...

I've probably explained the thing badly.

Yes, C++ has pointers to methods. However, they point
to method of some _class_ rather than to method of some
_object_. These are very different things. Of course,
you can store pointer to object elsewhere, but not
only it looks clumsy from the POV of end-user, there
is also a stupid limitation of method belonging to
exact given class, not even its child classes - and no
workaround for the problem. Such pointers are completely
useless in context of GUI library:

    void (CForm::*OnClick)(int x, y);
    ...
    class CMyForm: public CForm
    {
        public: void Click(int x, y);
    } MyForm;
    OnClick = CMyForm::Click;    // oops, won't work!

On other hand, Delphi pointers do point to method of
one concrete object, and they absolutely don't care
of its class - they simply treat method as a function
which has a context "this" pointer associated with it:

    var
        OnClick: procedure(x,y: integer) of object;
    ...
    type
        TMyForm = class(TForm);
            public procedure Click(x,y: integer);
        end;
    var
        MyForm: TMyForm;
    begin
        OnClick := MyForm.Click;    // everything's fine
    end;

"Pavel Minayev" <evilone omen.ru> writes:

"Juarez Rudsatz" <juarez mpsinf.com.br> wrote in message
news:9um1r4$1oeq$1 digitaldaemon.com...

 The problem is the endless repetition of this problem in all Delphi
 components and framewoks.
 Sometime can we think in a better solution for this problem.
 If you are thinking in adding event like mecanism for D is important to
 think in event cascating too.

IMHO the big problem here is that unlimited-depth cascading
requires growing stack, which would be much slower and
memory-consuming compared to a simple pair of pointers.
Cascading is not always that necessary, in most cases you
just want to set a handler to be called when a button is
clicked etc... if it'd really to become a part of a language,
it should be a separate type of the pointer, IMHO.