From: John Torjo (john.lists_at_[hidden])
Date: 2004-08-26 10:24:32
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
>>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.
-- John Torjo Freelancer -- john_at_[hidden] 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)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk