At first I want to describe the whole mechanism in a quite easy way:
The method QextMdiMainFrm::addWindow(..)
is probably the most important function in QextMDI. Here you take the view
under MDI control and set an initial state set as flags for the method
call. You can add a view as Attached, Detached (toplevel), Minimized, Maximized,
hidden and pre-positioned or pre-resized.
Question: Why do you use addWindow(..)? Why not setting
the mainframe window as MDI parent in the view contructor?
Answer: addWindow(..) is used because of a possible plugin library system in your application. Once the QextMdiChildView is created in a dynamically loaded library, it is still not noticed by the QextMdiMainFrm which is located in the executable. And the MDI view still doesn't know the mainframe. It is created with parent 0L first. If the plugin component GUI gets active, it calls addWindow wich is an internal reparent to the mainframe. Only then it gets under MDI control. To summarize, the GUI plugin doesn't know anything about the mainframe. |
In a bigger application often the mainframe is
not accessable. You just want to deal with your current view. If a view
is detached (in Toplevel mode), it still should be possible to call an
attach(..),
a
minimize(), maximize() or to ask about the current state
with for instance isAttached() or isDetached().
QextMdiChildView cares about all such stuff
involved in the MDI system. For example, if you call QextMdiChildView::minimize(),
it will minimize the view on desktop when it's detached or it will switch
to a mini window (just the caption bar remains) when the MDI view is attached.
That's why an extra class for MDI views.