Re: Event mechanisms for GUI's

["Randy Brukardt" <randy@rrsoftware.com>]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message
news:_AHSg.210879$1i1.191702@attbi_s72...
> Randy Brukardt wrote:
...
> > First of all, there is no simple or even satisfactory solution to this
> > problem. The trouble is that handling asynchronous events in a
sequential
> > programming language (or even a high-level parallel one like Ada) is a
poor
> > match. You complained about "a subprogram being called when a framework
> > pleases", but you have the same effect with any mechanism - the order of
> > operations depends on the events, not on the program. And any
well-designed
> > framework will make it clear when subprograms will be called and by
which
> > task.
>
> With configurable event queues, the user decides when events will be
> processed. With a callback mechanism, the framework makes those decisions.

That's *usually* a good thing -- it hides a lot of irrelevant detail from
the user, so they can concentrate on the important things. After all, 99% of
the time, you simply want to handle menu selections -- you don't care how
those are done. Yes, there is that 1% that might be harder, but I'm really
dubious that there is any one-size-fits-all solution.

...
> > My final conclusion is that all of the solutions have severe trade-offs;
> > none is anywhere near optimal. My advice to the OP is to select a
strategy
> > that works well for the problems that they want to solve, and not worry
too
> > much about "goodness" -- it's not going to happen in a GUI (that's why
GUI
> > builders are so indispensable).
>
> I've used callback, dispatching, and event-queue GUIs, and I prefer the
> latter. The code is much clearer.

My experience with Windows message loop (which is just a poorly implemented
event queue) using our old Win32 binding (which covered up the ugly stuff)
was that short programs were easier to write and understand, but that it
didn't scale well. And reuse was near impossible; that's easy for the tagged
dispatching version. OTOH, the dispatching version requires writing a type
and a bunch of subprograms for typical simple uses -- which is annoying. So
I think it is a case of many trade-offs, but no solution that is clearly
better.

                                      Randy.