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:
Dimitri Schoolwerth
2015-04-23 15:49:01 +04:00
parent 2d3f617b34
commit 8f8d58d193
1697 changed files with 3543 additions and 3543 deletions

View File

@@ -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*.

View File

@@ -108,8 +108,8 @@ protected:
}
private:
DECLARE_DYNAMIC_CLASS(MySpecialWidget)
DECLARE_EVENT_TABLE()
wxDECLARE_DYNAMIC_CLASS(MySpecialWidget);
wxDECLARE_EVENT_TABLE();
};
@endcode

View File

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

View File

@@ -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))
{

View File

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

View File

@@ -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()
{

View File

@@ -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()
{

View File

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