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).

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 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:

class myClass : public BWindow, public OtherClass

is safe, while

class myClass : public OtherClass, public BWindow

is not.

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.