What about considering a generic tree structure that represents composition of nodes, where that represents a model of hierarchy / containment of widgets.
already there ;) (in win32gui)
Have a nice way of name/referring to things in a relative sense to support re-composing without drama. This gives a way of addressing nodes. Sometime referred to as subject addressing. Needs to support implicit or explicit wild cards.
already there ;) See the function find_wnd (global) / find_wnd_range (global) / sub_wnd. You can find, for instance, descendants/children/siblings of a window - generically (all of them), or of a certain type (example: all edit controls).
Each node has sources and sinks. Read a property by attaching to the source. Write a property by sending a value to a sink. Calling a
too abstract. A certain node is a window. Based on its type, you can cast it to the desired type. Example: if it's an edit box, cast it to 'edit'. Then, use edit's properties.
method is sending a property to a sink. Events handlers attached to items in the hierarchy.
Yup, already there.
The event handler should be at the source node or higher in the hierarchy.
You attach an event handler to a certain control. Or more specifically, you create an event handler for a certain type of control. At runtime, all controls of that type are subclassed, and your event handler inserted there automatically.
An event handler is propagated down the composition hierarchy until it reaches a handler. That handler may allow the propagation to continue.
Also method call equivalents, sending a message to a sink at a particular level, could be propagated down the hierarchy. For example, setting a font for all composed items.
So there is a work flow between nodes a bit like the intensional style of programming with clocks. The structural composition adds a richness in allowing events to be handled at many sites and methods to have greater context.
This sounds so nice and abstract ;) However, I'm still missing concrete examples. IMO there are very few cases where you need to program this advanced. First of all, you should be able to handle an event that was sent to you. Then, eventually you can decide to send it to your parent, or whereever. Note that in the future win32gui will indeed allow dynamic binding of event handlers - that is, to be able to capture events sent from any widget. And as a side note, there is a much easier way to allow a property to be propagated down the hierarchy. For instance, you can have a special type, like cool_font, and you bind controls to it. Once you reset its value, it forwards it to all other controls - note that there's no event handling involved.
Another key would be iterator-like support for collections that widgets refer to and for access to items, selections that widgets have the state of...
note: find_wnd_range does return an iterator, which you can use to walk through various types of windows. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)