Drawbacks to nesting of child windows?

Question

Just for fun I'm developing a native Win32 port of Mozilla XUL. XUL allows to create complex nested structures of all kinds of layout boxes (hbox, vbox, grid, deck..). For my Windows implemenation it would be convenient to implement them as STATIC child windows. Because then I can position their child windows using x & y offsets independent of the position of the parent box.

However, this approach may lead to certain windows having a lot of nested child windows. And I wonder if there would be any disadvantages to such a situation. Does anyone here know?

Answer 1

A rough take on this:

• memory overhead for the window management on application- and os-side
• reduced speed due to calls to external library / os which do way more for windows than needed for your application
• possibly quite some overhead through long window message paths in complex layouts

It probably depends on wether you want a very fast implementation and do efficient buffered drawing by yourself or want it to work more reliably and with less time invested.

Answer 2

I've been down this path, and I don't recommend you actually make deep hierarchies of windows. Lots of Windows helper functions (e.g., IsDialogMessage) work better with "traditional" layouts. Also, windows in Windows are relatively heavy objects, mostly for historical reasons. So if you have tons of objects, you could run into limitations, performance problems, etc.

What I've done instead is to represent the deeply-nested layout as a tree of regular C++ objects that parallels the flatter hierarchy of actual windows. Some nodes of the object hierarchy have the HWNDs of the "real" windows they represent. You tell the hierarchy to layout, and the nodes apply the results to the corresponding windows.

For example, the root of the hierarchy may represent a dialog window, and the leaf nodes represent the child windows. But the hierarchy has several layers of non-window objects in between that know about layout.