Some rambling thoughts on things I'd like to see are:
1. run-time and compile-time configurability, especially with some
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
will dispatch. However this would lock you in at run-time if did
Behalf Of John Torjo like that 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.