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.
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 necessary.
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
If you handle this event, as well as
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.