RE: [boost] Java style GUI in C++

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-08-23 01:23:49

> Behalf Of John Torjo
> > Some rambling thoughts on things I'd like to see are:
> >
> > 1. run-time and compile-time configurability, especially with some
like
> > compile time specification language like layout capability.  There
was
> > some talk about this and some suggestions previously on this list.
> > Marrying this to run-time would be interesting.
> >
> > Perhaps at compile time you can decide if there is an explicit
handling
> > method and if not call something with your source and event type
that
> > will dispatch.  However this would lock you in at run-time if did
this
> > as a compile time metaprogramming thing that ending up optimizing to
a
> > function call equivalent but perhaps both options are appropriate...
> 
> that's more or less what win32gui does.
> 
> And more to the point, when you extend a window class, you can add
your
> own handlers into the picture.
> 
> Thus, you can end up with more event handlers for the same
> event/command/notificiation.
> 
> This is TOTALLY ok.
> Whenever a handler for an event/command/notification gets called, it
can
> decide what to consider this event:
> - event_not_handled: I consider this handler did not handle this
event.
> If more handlers exist, call them. If no more handlers, call default
(in
> our case, DefWindowProc)
> 
> - event_is_handling. I did handle his event, but it's ok if other
> handlers handle it too. So, if there are other handlers, call them
too.
> After all handlers are called, DO NOT call default (in our case,
> DefWindowProc).
> 
> - event_handled: I handled this event. DO NOT call other handlers, nor
> the default( DefWindowProc).
> 
> 
> I thinks this handles most (if not all) cases.

Yep, in my mind it should be handled by the highest level event handler
in the structural tree composite thingo that represents the ui layout.
That event handler has the option to allow dispatch to the next lower
level handler.

I was thinking that you would attach event handlers for messages from
sources to any place in the structural ui tree.  It is handled by the
highest handler in the structural tree or it is ignored if there is no
handler.

> >
> > 2. reverse structural inheritance of events handler equivalents.
> > Widgets are composed of other widgets.  A window may handle the
click,
> > or prevent it, for a child.  You can attach a handler for a named
event
> > at any point in the composition / structural hierarchy, it doesn't
have
> > to be the source, but is aware of it.  Handling goes down the
hierarchy
> > to source.
> 
> In fact, I think it should be quite reversed.
> If a window cannot handle a command/notification, forward it to its
> parent and so on - until someone handles it or reaches top.

I think it should be the other way around, if I understand it.  You need
to be able to over-ride the behaviour of your components by interposing
another handler.  E.g. don't do the normal stock window click event do
this instead (which may also continue the chain down...).  More
importantly, should be able to disable and enable all contained (child)
messages.  Doing so by category as someone else suggested would be
nice... e.g. all drag drop, all mouse, etc...

Goodluck, your lib sounds interesting.

Matt.

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments.  Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited.  Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument.  Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.