Use wx-prefixed macros throughout the repository.
Change {DECLARE,IMPLEMENT}_*CLASS and {DECLARE,BEGIN,END}_EVENT_TABLE occurrences to use the wx-prefixed version of the macros.
This commit is contained in:
@@ -41,7 +41,7 @@ public:
|
||||
virtual bool OnInit();
|
||||
};
|
||||
|
||||
IMPLEMENT_APP(DerivedApp)
|
||||
wxIMPLEMENT_APP(DerivedApp);
|
||||
|
||||
bool DerivedApp::OnInit()
|
||||
{
|
||||
@@ -53,14 +53,14 @@ bool DerivedApp::OnInit()
|
||||
}
|
||||
@endcode
|
||||
|
||||
Note the use of IMPLEMENT_APP(appClass), which allows wxWidgets to dynamically
|
||||
Note the use of wxIMPLEMENT_APP(appClass), which allows wxWidgets to dynamically
|
||||
create an instance of the application object at the appropriate point in
|
||||
wxWidgets initialization. Previous versions of wxWidgets used to rely on the
|
||||
creation of a global application object, but this is no longer recommended,
|
||||
because required global initialization may not have been performed at
|
||||
application object construction time.
|
||||
|
||||
You can also use DECLARE_APP(appClass) in a header file to declare the wxGetApp
|
||||
You can also use wxDECLARE_APP(appClass) in a header file to declare the wxGetApp
|
||||
function which returns a reference to the application object. Otherwise you can
|
||||
only use the global @c wxTheApp pointer which is of type @c wxApp*.
|
||||
|
||||
|
@@ -108,8 +108,8 @@ protected:
|
||||
}
|
||||
|
||||
private:
|
||||
DECLARE_DYNAMIC_CLASS(MySpecialWidget)
|
||||
DECLARE_EVENT_TABLE()
|
||||
wxDECLARE_DYNAMIC_CLASS(MySpecialWidget);
|
||||
wxDECLARE_EVENT_TABLE();
|
||||
};
|
||||
@endcode
|
||||
|
||||
|
@@ -38,9 +38,9 @@ be running on are unusually constrained (notice that when asserts are disabled
|
||||
their condition is not even evaluated so the only run-time cost is a single
|
||||
condition check and the extra space taken by the asserts in the code).
|
||||
|
||||
This automatic deactivation of debugging code is done by IMPLEMENT_APP() macro
|
||||
so if you don't use you may need to explicitly call wxDISABLE_DEBUG_SUPPORT()
|
||||
yourself.
|
||||
This automatic deactivation of debugging code is done by wxIMPLEMENT_APP()
|
||||
macro so if you don't use you may need to explicitly call
|
||||
wxDISABLE_DEBUG_SUPPORT() yourself.
|
||||
|
||||
Also notice that it is possible to build your own application with a different
|
||||
value of wxDEBUG_LEVEL than the one which was used for wxWidgets itself. E.g.
|
||||
|
@@ -114,9 +114,9 @@ wxDocument class, you need to derive a new class and override at least the
|
||||
member functions SaveObject and LoadObject. SaveObject and LoadObject will be
|
||||
called by the framework when the document needs to be saved or loaded.
|
||||
|
||||
Use the macros DECLARE_DYNAMIC_CLASS and IMPLEMENT_DYNAMIC_CLASS in order to
|
||||
allow the framework to create document objects on demand. When you create a
|
||||
wxDocTemplate object on application initialization, you should pass
|
||||
Use the macros wxDECLARE_DYNAMIC_CLASS and wxIMPLEMENT_DYNAMIC_CLASS in order
|
||||
to allow the framework to create document objects on demand. When you create
|
||||
a wxDocTemplate object on application initialization, you should pass
|
||||
CLASSINFO(YourDocumentClass) to the wxDocTemplate constructor so that it knows
|
||||
how to create an instance of this class.
|
||||
|
||||
@@ -139,8 +139,8 @@ To use the abstract wxView class, you need to derive a new class and override
|
||||
at least the member functions OnCreate, OnDraw, OnUpdate and OnClose. You will
|
||||
probably want to respond to menu commands from the frame containing the view.
|
||||
|
||||
Use the macros DECLARE_DYNAMIC_CLASS and IMPLEMENT_DYNAMIC_CLASS in order to
|
||||
allow the framework to create view objects on demand. When you create a
|
||||
Use the macros wxDECLARE_DYNAMIC_CLASS and wxIMPLEMENT_DYNAMIC_CLASS in order
|
||||
to allow the framework to create view objects on demand. When you create a
|
||||
wxDocTemplate object on application initialization, you should pass
|
||||
CLASSINFO(YourViewClass) to the wxDocTemplate constructor so that it knows how
|
||||
to create an instance of this class.
|
||||
@@ -295,10 +295,10 @@ In order to respond to a file load command from one of these identifiers, you
|
||||
need to handle them using an event handler, for example:
|
||||
|
||||
@code
|
||||
BEGIN_EVENT_TABLE(wxDocParentFrame, wxFrame)
|
||||
wxBEGIN_EVENT_TABLE(wxDocParentFrame, wxFrame)
|
||||
EVT_MENU(wxID_EXIT, wxDocParentFrame::OnExit)
|
||||
EVT_MENU_RANGE(wxID_FILE1, wxID_FILE9, wxDocParentFrame::OnMRUFile)
|
||||
END_EVENT_TABLE()
|
||||
wxEND_EVENT_TABLE()
|
||||
|
||||
void wxDocParentFrame::OnExit(wxCommandEvent& WXUNUSED(event))
|
||||
{
|
||||
|
@@ -40,8 +40,8 @@ same code to draw to several different devices. You can draw using the member
|
||||
functions of wxDC, such as wxDC::DrawLine and wxDC::DrawText. Control colour on
|
||||
a window (wxColour) with brushes (wxBrush) and pens (wxPen).
|
||||
|
||||
To intercept events, you add a DECLARE_EVENT_TABLE macro to the window class
|
||||
declaration, and put a BEGIN_EVENT_TABLE ... END_EVENT_TABLE block in the
|
||||
To intercept events, you add a wxDECLARE_EVENT_TABLE macro to the window class
|
||||
declaration, and put a wxBEGIN_EVENT_TABLE ... wxEND_EVENT_TABLE block in the
|
||||
implementation file. Between these macros, you add event macros which map the
|
||||
event (such as a mouse click) to a member function. These might override
|
||||
predefined event handlers such as for wxKeyEvent and wxMouseEvent.
|
||||
|
@@ -30,8 +30,8 @@ all the others. This macro is limited to wxWidgets classes only and only works
|
||||
with pointers (unlike the real dynamic_cast which also accepts references).
|
||||
|
||||
Each class that you wish to be known to the type system should have a macro
|
||||
such as DECLARE_DYNAMIC_CLASS just inside the class declaration. The macro
|
||||
IMPLEMENT_DYNAMIC_CLASS should be in the implementation file. Note that these
|
||||
such as wxDECLARE_DYNAMIC_CLASS just inside the class declaration. The macro
|
||||
wxIMPLEMENT_DYNAMIC_CLASS should be in the implementation file. Note that these
|
||||
are entirely optional; use them if you wish to check object types, or create
|
||||
instances of classes using the class name. However, it is good to get into the
|
||||
habit of adding these macros for all classes.
|
||||
@@ -39,13 +39,13 @@ habit of adding these macros for all classes.
|
||||
Variations on these macros are used for multiple inheritance, and abstract
|
||||
classes that cannot be instantiated dynamically or otherwise.
|
||||
|
||||
DECLARE_DYNAMIC_CLASS inserts a static wxClassInfo declaration into the class,
|
||||
initialized by IMPLEMENT_DYNAMIC_CLASS. When initialized, the wxClassInfo
|
||||
object inserts itself into a linked list (accessed through wxClassInfo::first
|
||||
and wxClassInfo::next pointers). The linked list is fully created by the time
|
||||
all global initialisation is done.
|
||||
wxDECLARE_DYNAMIC_CLASS inserts a static wxClassInfo declaration into the
|
||||
class, initialized by wxIMPLEMENT_DYNAMIC_CLASS. When initialized, the
|
||||
wxClassInfo object inserts itself into a linked list (accessed through
|
||||
wxClassInfo::first and wxClassInfo::next pointers). The linked list is fully
|
||||
created by the time all global initialisation is done.
|
||||
|
||||
IMPLEMENT_DYNAMIC_CLASS is a macro that not only initialises the static
|
||||
wxIMPLEMENT_DYNAMIC_CLASS is a macro that not only initialises the static
|
||||
wxClassInfo member, but defines a global function capable of creating a dynamic
|
||||
object of the class in question. A pointer to this function is stored in
|
||||
wxClassInfo, and is used when an object should be created dynamically.
|
||||
@@ -63,9 +63,9 @@ wxClassInfo object instead, then you can simply call wxClassInfo::CreateObject.
|
||||
|
||||
@section overview_rtti_classinfo wxClassInfo
|
||||
|
||||
This class stores meta-information about classes. An application may use macros
|
||||
such as DECLARE_DYNAMIC_CLASS and IMPLEMENT_DYNAMIC_CLASS to record runtime
|
||||
information about a class, including:
|
||||
This class stores meta-information about classes. An application may use
|
||||
macros such as wxDECLARE_DYNAMIC_CLASS and wxIMPLEMENT_DYNAMIC_CLASS to
|
||||
record runtime information about a class, including:
|
||||
|
||||
@li Its position in the inheritance hierarchy.
|
||||
@li The base class name(s) (up to two base classes are permitted).
|
||||
@@ -89,7 +89,7 @@ In a header file frame.h:
|
||||
@code
|
||||
class wxFrame : public wxWindow
|
||||
{
|
||||
DECLARE_DYNAMIC_CLASS(wxFrame)
|
||||
wxDECLARE_DYNAMIC_CLASS(wxFrame);
|
||||
|
||||
private:
|
||||
wxString m_title;
|
||||
@@ -102,7 +102,7 @@ public:
|
||||
In a C++ file frame.cpp:
|
||||
|
||||
@code
|
||||
IMPLEMENT_DYNAMIC_CLASS(wxFrame, wxWindow)
|
||||
wxIMPLEMENT_DYNAMIC_CLASS(wxFrame, wxWindow);
|
||||
|
||||
wxFrame::wxFrame()
|
||||
{
|
||||
|
@@ -401,12 +401,12 @@ public:
|
||||
{
|
||||
Close();
|
||||
}
|
||||
DECLARE_EVENT_TABLE();
|
||||
wxDECLARE_EVENT_TABLE();
|
||||
};
|
||||
|
||||
BEGIN_EVENT_TABLE(TestWnd,TestWnd_Base)
|
||||
wxBEGIN_EVENT_TABLE(TestWnd,TestWnd_Base)
|
||||
EVT_BUTTON(XRCID("B"), TestWnd::OnBPressed)
|
||||
END_EVENT_TABLE()
|
||||
wxEND_EVENT_TABLE()
|
||||
@endcode
|
||||
|
||||
It is also possible to access the wxSizerItem of a sizer that is part of a
|
||||
@@ -451,7 +451,7 @@ public:
|
||||
virtual bool CanHandle(wxXmlNode *node);
|
||||
|
||||
// Register with wxWidgets' dynamic class subsystem.
|
||||
DECLARE_DYNAMIC_CLASS(MyControlXmlHandler)
|
||||
wxDECLARE_DYNAMIC_CLASS(MyControlXmlHandler);
|
||||
};
|
||||
@endcode
|
||||
|
||||
@@ -459,7 +459,7 @@ The implementation of your custom XML handler will typically look as:
|
||||
|
||||
@code
|
||||
// Register with wxWidgets' dynamic class subsystem.
|
||||
IMPLEMENT_DYNAMIC_CLASS(MyControlXmlHandler, wxXmlResourceHandler)
|
||||
wxIMPLEMENT_DYNAMIC_CLASS(MyControlXmlHandler, wxXmlResourceHandler);
|
||||
|
||||
MyControlXmlHandler::MyControlXmlHandler()
|
||||
{
|
||||
|
@@ -2554,7 +2554,7 @@ The subclass must satisfy a number of requirements:
|
||||
|
||||
-# It must be derived from the class specified in @c class attribute.
|
||||
-# It must be visible in wxWidget's pseudo-RTTI mechanism, i.e. there must be
|
||||
a DECLARE_DYNAMIC_CLASS() entry for it.
|
||||
a wxDECLARE_DYNAMIC_CLASS() entry for it.
|
||||
-# It must support two-phase creation. In particular, this means that it has
|
||||
to have default constructor.
|
||||
-# It cannot provide custom Create() method and must be constructible using
|
||||
|
Reference in New Issue
Block a user