Mathew Robertson wrote:
I could really use some examples here ;) Because I really can't think of any. Maybe we are mis-reading eachother ;)
What about considering a generic tree structure that represents composition of nodes, where that represents a model of hierarchy / containment of widgets.
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.
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 method is sending a property to a sink. Events handlers attached to items in the hierarchy.
The event handler should be at the source node or higher in the hierarchy.
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.
Add the context of getting a property from any parent, what is my parent font, colour, stock symbol, warehouse location and you end up with a richness of contextually aware widgets that can be composed with limited programming.
This conceptual framework for me forms a significant aspect for the basis for an ideal gui. Most gui frameworks kind of work in this manner to some extent.
One main problem with this is that (generally speaking) there are at more than one heirachy that needs to be maintained: 1. The parent-child window relationship (eg this is needed for setting font on all children, hiding all children, etc) 2. Tab-order relationship 3. Event propogation heirachy
...just to name a few. From the description above, point 2 is definately not handled. And points
couldn't agree more ;) That's why in win32gui I hold a map of all windows. Then when you want to find some windows that match a criteria (like, children, descendants, having a certain type, etc.), you ask for them (find_wnd_range<>) and simply iterate them. 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)