From WxWiki
Jump to navigation Jump to search
Official Classes SmallBlocks.png Archive Containers Controls Data Structures Database Date & Time Debug Device Contexts Dialogs Document & Views Drag & Drop Events Filesystem Frames Graphics Grid Cell Help HTML Logging Miscellaneous Networking Printing Sizers Streams Threading Windows

wxWindow is the base class for all windows and represents any visible object on screen.

All controls, top level windows and so on are windows. Sizers and device contexts are not, however, as they don't appear on screen themselves.

Please note that all children of the window will be deleted automatically by the destructor before the window itself is deleted which means that you don't have to worry about deleting them manually. Please see the window deletion overview for more information.

Also note that in this, and many others, wxWidgets classes some GetXXX() methods may be overloaded (as, for example, wxWindow::GetSize or wxWindow::GetClientSize). In this case, the overloads are non-virtual because having multiple virtual functions with the same name results in a virtual function name hiding at the derived class level (in English, this means that the derived class has to override all overloaded variants if it overrides any of them). To allow overriding them in the derived class, wxWidgets uses a unique protected virtual DoGetXXX() method and all GetXXX() ones are forwarded to it, so overriding the former changes the behaviour of the latter.

Checking Visibility

All controls in wxWidgets derive from wxWindow and hence inherit its IsShown() method which can be used to check for their visibility (see also IsShownOnScreen()).


wxWindow::GetChildren() returns wxWindowList&, not wxList&. I got a warning at compile time when doing:

wxList& mylist = pWindow->GetChildren();

The warning was: [Warning] `operator 5' is deprecated (declared at C:/Dev-Cpp/include/wx-2.6/wx/list.h:1112)

Replacing wxList& with wxWindowList& fixed it.


Eric Jensen writes on wx-users::

i was playing around with wxWindow::RegisterHotKey() and noticed that        
the virtualKeyCode parameter that this function uses, expects the           
Window keycodes and not the wxWidgets keycodes (e.g VK_F9 rather             
than WXK_F9).                                                              
Although this was not difficult to find, it should be mentioned in the       
documetation. However, if this function ever gets implemented on other     
platforms, using the 'normalized' wxWidgets keycode might become             


Your wxWindow-derived class will not receive this event if you create the window by calling the wxWindow constructor (as in MyWin::MyWin(wxWindow*parent) : wxWindow(parent,...)) because your object is still a wxWindow when the window is created. Call Create(parent,...) from the body of your constructor instead.

Also, don't try to receive EVT_WINDOW_DESTROY events in your own window, as is well documented in the official docs. Override Destroy() instead.


If you handle this event, as well as EVT_RIGHT_DOWN or EVT_MIDDLE_DOWN, and do not call event.Skip() you will most likely want to call SetFocus(). Failure to do so will prevent the window from receiving keyboard and mouse wheel events.


Don't forget to call RemoveEventHandler() or PopEventHandler() before deleting the object passed to PushEventHandler()

wxWidgets will not automatically cleanup the event handlers when you are closing the application. It will cause a number of weird segfaults when closing your application.

See Also