Organization of GUIs

[Tim Roberts]

Michael Mossey <michaelmossey at gmail.com> wrote:
>
>I am now wondering if I should write a GUI so that everything is in a
>true hierarchy, rather than a tangle of objects with democratic
>relationships---and more specifically, that messages (which may cause
>state to be changed in the receiver of the message) should first go up
>the hierarchy until they reach the right level, and then down to the
>ultimate receiver of the message. This way a parent object in the
>hierarchy has complete visibility and control of messages passing
>between its children, leading to the possibility of consolidating the
>code and documentation about the children's mutability in one place
>(the parent).

There are practical considerations here that make such a pure arrangement
difficult.

For example, consider a relatively complicated dialog GUI, with several
sub-frames, maybe a splitter, couple of group boxes, containing edit boxes
and buttons, etc.  Now, consider what happens when a button gets pressed.
Usually, you want to take some action that is global to the whole dialog.
The button will see the mouse down and mouse up messages, but it doesn't
know what ACTION should be taken.

It's possible to handle that, but each layer has to know about
"notifications", and has to be able to hand "notifications" up the
hierarchy tree until it gets to someone who knows what to do about it.
-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.