The way that events are handled has been radically changed in wxWindows 2.0. Please read the topic 'Event handling overview' in the wxWindows 2.0 manual for background on this.
Instead of callbacks for panel items, menu command events, control commands and other events are directed to the originating window, or an ancestor, or an event handler that has been plugged into the window or its ancestor. Event handlers always have one argument, a derivative of wxEvent.
For menubar commands, the OnMenuCommand member function will be replaced by a series of separate member functions, each of which responds to a particular command. You need to add these (non-virtual) functions to your frame class, add a DECLARE_EVENT_TABLE entry to the class, and then add an event table to your implementation file, as a BEGIN_EVENT_TABLE and END_EVENT_TABLE block. The individual event mapping macros will be of the form:
BEGIN_EVENT_TABLE(MyFrame, wxFrame) EVT_MENU(MYAPP_NEW, MyFrame::OnNew) EVT_MENU(wxID_EXIT, MyFrame::OnExit) END_EVENT_TABLE()Control commands, such as button commands, can be routed to a derived button class, the parent window, or even the frame. Here, you use a function of the form EVT_BUTTON(id, func). Similar macros exist for other control commands.
To intercept other events, you used to override virtual functions, such as OnSize. Now, while you can use the OnSize name for such event handlers (or any other name of your choice), it has only a single argument (wxSizeEvent) and must again be 'mapped' using the EVT_SIZE macro. The same goes for all other events, including OnClose (although in fact you can still use the old, virtual form of OnClose for the time being).