We need to avoid the shell placement/positioning responses when not actually a top-level view. These upset the initial draw-order of the controls to the extent that the tree views are painted but then erased by the nearest parent that doesn't have WS_CLIPCHILDREN set.
There may be some other behaviour of ShellView
that is not appropriate in the case where the view is actually being hosted in some kind of MDI wrapper, but this is sufficient for now. It isn't strictly necessary to avoid the attempted addition of a menu bar (which fails silently anyway), nor the setting of Window icons, but both do nothing useful so may as well be skipped.
A better solution might be to adjust the class of the view being created by substituting another through some kind of STB override, or perhaps to have pluggable shell behaviour. Either approache could be used to avoid having a proliferation of #isTopView tests (of which there are already a number, and which is really a "type" test).
…Space
We need to avoid the shell placement/positioning responses when not actually a top-level view. These upset the initial draw-order of the controls to the extent that the tree views are painted but then erased by the nearest parent that doesn't have WS_CLIPCHILDREN set.
There may be some other behaviour of ShellView that is not appropriate in the case where the view is actually being hosted in some kind of MDI wrapper, but this is sufficient for now. It isn't strictly necessary to avoid the attempted addition of a menu bar (which fails silently anyway), nor the setting of Window icons, but both do nothing useful so may as well be skipped. A better solution might be to adjust the class of the view being created by substituting another through some kind of STB override, or perhaps to have pluggable shell behaviour. Either approache could be used to avoid having a proliferation of #isTopView tests (of which there are already a number, and which is really a "type" test).