Wim Veldhuis wrote in a message to Jonathan de Boyne Pollard:

 WV> Hello Jonathan, sorry to but in like this, but are you sure
 WV> about the above ? AFAIK the sources for the BIDS and OWL
 WV> classes do not something Borland C++ specific. OWL is
 WV> platform dependant (Windows) but from a language point of
 WV> view it is just C++ as proposed by the ANSI committee. 

It's not. Borland does some nasty things while dispatching messages. They
rely on some low-level routines and the internal memory layout of method
dispatch tables and VMT's. I'm currently implementing a class library in
Ada, and the hardest part is to find a good mapping between handles and
objects, and between PM messages and method calls.

Furthermore I want to map the PM window hierarchy (windows, parents,
child-windows etc.) onto container classes. Basically there are two class
hierarchies: the inheritance hierarchy (the one often seen in
class-browsers) and the 'parent-child' hierarchy. Since the last one can't
be explicitly specified using current object-orented languages, I'm looking
for a structured way to do so.

Ideally I want to be able to define a special type of dialog box as a set
of general objects, like buttons, labels and input boxes. It should be
possible just specify the internal relations, without worrying about
obvious implementation details.

Simplified, the definition of my application would look like:

  Main_Window := Standard_Window + Toolbar + Menu + Status_Line;

The "+" would be the link operator, linking the previously
created Toolbar, Menu and Status_Line to the Standard_Window. So, it would
translate to:

  Main_Window := Standard_Window;
  Link(Main_Window, Toolbar);
  Link(Main_Window, Menu);
  Link(Main_Window, Status_Line);

Since Ada95 can have multiple polymorphic arguments, different functions
can be implemented for any pair of argument types, and inheritance can be
used for both arguments. Object linking should be intelligent, so a
Status_Line might reserve the bottom portion of its parent's client-area
while the Toolbar might want another portion.

Last but not least, linked objects should be able to communicate and
interact properly without explicit help of their parents. A toolbar might
want to add menu items to the menu (if available) to allow configuration,
and the status-line might need to display the current menu item.

Last but not least all of these linked objects might need to override the
window command handling of their parent.

And here comes the problem: how do I *efficiently* dispatch messages the
methods of the objects that need to handle them.

Of course I could just let every Window class let have a virtual Message
Handler, and have parents to first call all their children's
message-handlers and then execute their own if the children can't handle
them, all using huge conditional (switch/select/case) statements. It's the
way it is done using C. 

Alternativey you could hack the dispatching tables and such, like Borland
does, but I won't do that for good (compatibility, portability) reasons.
All ideas would be greatly appreciated, and source snippets in C++, Ada95
or another OO language would be fantastic.

Groetjes, Geert 
--- timEd/2 1.01+