Re: [boost] Re: Re: Re: Java style GUI in C++

From: John Torjo (john.lists_at_[hidden])
Date: 2004-08-26 10:20:13

>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_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)