"Pavel Minayev" <evilone@omen.ru> wrote in message news:a607ha$1psa$1@digitaldaemon.com...
> "Ruslanas Abdrachimovas" <anubis@03bar.ktu.lt> wrote in message news:3C839AA7.1090403@03bar.ktu.lt...
>
> > Event dispatcher queue in separate thread... And who wants to listen to
> > say JButton instance just does
> > button.addActionListener(<ref to object implementing action listener
> > interface>);
>
> Now I've read the specification, I understand... I'd thought of
> something like this already, but it requires tons of classes
> and objects to be created to handle all events in a more or
> less complex window... also listener objects will have to store
> pointer to their owner, and won't get access to privates - bad!
> Java provides a workaround in the form of anonymous inner classes,
> unfortunately there isn't anything like that in D.
>
> I've been thinking of another, not very safe, but (IMO) better
> alternative. Here's a sample snippet:
>
>     /* library code */
>     interface Handler { }  // just a dummy, to provide some typechecking
>     private interface _Handler: Handler { void handle(Event); }
>
>     class Button
>     {
>         Handler onClick;
>         ...
>
>         void clicked()
>         {
>             (cast(_Handler) onClick).handle(new ClickEvent);
>         }
>     }
>
>
>     /* user code */
>     interface cmdOk_Click: Handler { void cmdOk_Click(Event); }
>     interface cmdCancel_Click: Handler { void cmdCancel_Click(Event); }
>
>     class MyForm: Form, cmdOk_Click, cmdCancel_Click
>     {
>         Button cmdOk, cmdCancel;
>
>         this()
>         {
>             ...
>             cmdOk.onClick = cast(cmdOk_Click) this;
>             cmdCancel.onClick = cast(cmdCancel_Click) this;
>         }
>
>         void cmdOk_Click(Event e) { ... }
>         void cmdCancel_Click(Event e) { ... }
>     }

Forgive me for being dense and/or naive, but I still don't see the difficulty with dispensing with intermediate event-receptor classes, but rather subclass all your GUI objects from supplied classes with predefined event-methods, and then implementing those methods you want.

And if you think the difficulty is "too many potential callback methods leading to overly large vtbls" then see my other post regarding this issue:

news://news.digitalmars.com/a6054t$1o03$1@digitaldaemon.com

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a609d8$1rd6$1@digitaldaemon.com...

> Forgive me for being dense and/or naive, but I still don't see the difficulty with dispensing with intermediate event-receptor classes, but rather subclass all your GUI objects from supplied classes with predefined event-methods, and then implementing those methods you want.

No MI, so you can't subclass from many classes, only from one. So you have to use interfaces. Now consider the following one:

    interface IButtonEvents
    {
        void onButtonClick(Event);
    }

And a form:

    class MyForm: Form, IButtonEvents
    {
        Button cmdOk, cmdCancel;

        onButtonClick(Event e)
        {
        }
    }

Now onButtonClick() will receive click messages from BOTH cmdOk and cmdCancel, and you have to use switch to provide separate implementation for each case - and what if there are 20 buttons on the form?.. this isn't far from your typical WindowProc style.

What I want is the ability to bind a separate function for each event of each distinct _object_ (and not class). So if you have 10 buttons on your form, you should be able to have 10 onClick handlers, one for each button. I don't see how it can be done this way.

> And if you think the difficulty is "too many potential callback methods leading to overly large vtbls" then see my other post regarding this
issue:

Not a problem, IMO. If you have 30-40 event handlers, it's just 120-160 additional bytes in the vtable per class - not something worthy even remembering about.

Pavel Minayev a écrit :

> This is something I would really like to hear others' opinions
> about: event handling in my GUI library, WinD. Currently, it
> tries to mimic the Borland's approach (pointers to methods),
> and does it by some rather dirty hacks, like modifying the
> vtable at run-time, besides, it's highly error-prone... Needless
> to say, I'm not very satisfied with this solution. Should it
> be dropped in favor of other method, and if so, which? I only
> have one idea: a single handler for ALL events from this and
> child controls:
>
>     class MyForm: Form
>     {
>         TextBox txtName;
>         Button cmdOk;
>
>         ...
>
>         void eventHandler(Event e)
>         {
>             switch (e.sender)
>             {
>             case txtName:
>                 switch (e.type)
>                 {
>                 case Event.Click:
>                     ...
>                 case Event.Change:
>                     ...
>                 }
>                 break;
>             case cmdOk:
>                 if (e.type == Event.Click)
>                     ...
>             }
>         }
>     }
>
> This method is very simple to implement, but it results in code hard to write, read and understand, and limits the enchancement capabilities (adding new events could be a problem).
>
> Other ideas?

Warning:
This post is very theorical and not pactical at all.
I'm not very aware of how D is now. I don't use it yet.
I hope this post will not lower my already poor signal/noise ratio.

Lets go:
A system that generate events, is like an electronic chip, witch pins
change of state to signal something.
It you want your own chip to react to the event, there is no other way than
to connect an input pin
of your chip to the proper output signal.
In HDL (Hardware Description Langage), to connect an input pin to an output
pin, you use the '=' operator.
In my opinion, it would be nice if interfaces and signal handling in D
takes inspiration from HDL langages.
(may be it is already the case for interfaces)
You defines 'chips' (classes) with input and output and you connect them
programmaticaly, at compile time
or at run time (multiplexers).
Note that an output pin can be connected to many input pins, and all input
pins recieve the information at the
same time. A compiler should emulate that. (carefull with race conditions !
the compiler should detect them)

Roland

Hmmm....  Okay, I think I'm seeing the issue more correctly.

In VB, event handlers are located symbolically.  If a control's name is "Button1" and it's trying to deliver a Click event, it looks for a method "Button1_Click" in the form.  This is mighty convenient, but also very symbolic.  Hmmm.

I'm finding myself resorting to the Java style, with event handler classes, but not funky anonymous inner classes.  And I'm not really liking it.

If only D had *macros* this could be done rather conveniently.  (I don't know why no one else can see the need for macros.  Just you wait until I've written up the spec for the macro language; you'll see.)

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a62fdv$2ra5$1@digitaldaemon.com...

> In VB, event handlers are located symbolically.  If a control's name is "Button1" and it's trying to deliver a Click event, it looks for a method "Button1_Click" in the form.  This is mighty convenient, but also very symbolic.  Hmmm.
>
> I'm finding myself resorting to the Java style, with event handler
classes,
> but not funky anonymous inner classes.  And I'm not really liking it.

I'd prefer pointers to methods of objects (delegates in C# terminology), as seen in Delphi/VCL and C#. They solve all the problems, IMO:

    class Button
    {
        delegate void (*onClick)(Event);
        ...

        void clicked()
        {
            onClick(new Event);
        }
    }

    class MyForm: Form
    {
        Button cmdOk, cmdCancel;
        ...

        this()
        {
            cmdOk.onClick = &this.cmdOk_Click;
            cmdCancel.onClick = &this.cmdCancel_Click;
        }

        void cmdOk_Click(Event e) { ... }
        void cmdCancel_Click(Event e) { ... }
    }

Unfortunately, delegates are very unlikely to be seen in D 1.0, from what I've heard...