Boost logo

Boost :

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
-- john_at_[hidden]
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- v1.3beta released - check out splitter/simple_viewer, 
   a File Explorer/Viewer all in about 200 lines of code!
Professional Logging Solution for FREE
-- (logging           - C++)
--         (viewing/filtering - Win32)
--        (debugging         - Win32)

Boost list run by bdawes at, gregod at, cpdaniel at, john at