BWindow¶
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 (bypassing the App Server), you
should use a BDirectWindow or BWindowScreen object (both classes are
defined in the Game Kit).
Creating and Using a BWindow¶
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 to 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 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.
Warning
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 how the window thread and
C++ deletes objects of a multiply-inherited class. In other words:
class myClass : public BWindow, public OtherClass
is safe, while
class myClass : public OtherClass, public BWindow
is not.