A BWindow
object represents a window that can be displayed on the screen,
and that can be the target of user events. You almost always create your
own BWindow
subclass(es) rather than use direct instances of
BWindow.
BWindow
objects draw windows by talking to the App Server. If you want to
take over the entire screen or draw directly into the graphics card's
frame buffer (by-passing the App Server), you should use a
BDirectWindow
or BWindowScreen
object (both classes are defined in the Game Kit).
You must create your
BApplication
object (be_app) before you create any
windows. be_app needn't be running to construct—or even
show—a window, but it must be running for the window to receive
notifications of user events (mouse clicks, key presses, etc.).
Typically, the first thing you do with your
BWindow is add
BViews to it,
through the
AddChild()
function. Again, be_app needn't be running at this
point, nor must the window be showing.
Even though it inherits from
BLooper,
you never invoke
AddChild()Run() on a
BWindow.
Instead, you call
Show().
In addition to putting the window
on-screen, the first (and only the first)
Show()
invocation starts the
BWindow's
message loop. To remove a window from the screen without
interrupting the object's message loop, use
Hide().
Other message loop details (locking and quitting in particular) are
handled as described in the
BLooper class.
If you create a BWindow-derived
class that uses multiple inheritance,
make sure the first class your mixin class inherits from is
BWindow;
otherwise, you'll crash when you try to close the window. This happens
because of an interaction between the window thread how C++ deletes
objects of a multiply-inherited class. In other words:
classmyClass: publicBWindow, publicOtherClass
is safe, while
classmyClass: publicOtherClass, publicBWindow
is not.
