Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

commit remaining portions of #10087

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@56970 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Francesco Montorsi
2008-11-25 17:26:11 +00:00
parent 582699e1ac
commit 2a63871948
1 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
docs/doxygen/overviews/eventhandling.h
View File

@@ -182,7 +182,7 @@ handle the events first and, as before, this class must derive from
wxEvtHandler (usually indirectly via wxWindow). See the declaration of MyFrame wxEvtHandler (usually indirectly via wxWindow). See the declaration of MyFrame
in the previous section. However the similarities end here and both the syntax in the previous section. However the similarities end here and both the syntax
and the possibilities of handling events in this way are rather different. and the possibilities of handling events in this way are rather different.
Let us start by looking at the syntax: the first obvious difference is that you Let us start by looking at the syntax: the first obvious difference is that you
need not use @c DECLARE_EVENT_TABLE() nor @c BEGIN_EVENT_TABLE and the need not use @c DECLARE_EVENT_TABLE() nor @c BEGIN_EVENT_TABLE and the
associated macros. Instead, in any place in your code, but usually in associated macros. Instead, in any place in your code, but usually in
@@ -524,44 +524,44 @@ uniquely determine window identity in the event system (though you can use it
for other purposes). In fact, identifiers do not need to be unique for other purposes). In fact, identifiers do not need to be unique
across your entire application as long they are unique within the across your entire application as long they are unique within the
particular context you're interested in, such as a frame and its children. You particular context you're interested in, such as a frame and its children. You
may use the @c wxID_OK identifier, for example, on any number of dialogs so may use the @c wxID_OK identifier, for example, on any number of dialogs
long as you don't have several within the same dialog. as long as you don't have several within the same dialog.
If you pass @c wxID_ANY to a window constructor, an identifier will be If you pass @c wxID_ANY to a window constructor, an identifier will be
generated for you automatically by wxWidgets. This is useful when you don't generated for you automatically by wxWidgets. This is useful when you don't
care about the exact identifier either because you're not going to process the care about the exact identifier either because you're not going to process the
events from the control being created at all or because you process the events events from the control being created or because you process the events
from all controls in one place (in which case you should specify @c wxID_ANY from all controls in one place (in which case you should specify @c wxID_ANY
in the event table or wxEvtHandler::Connect call in the event table or wxEvtHandler::Connect call
as well. The automatically generated identifiers are always negative and so as well). The automatically generated identifiers are always negative and so
will never conflict with the user-specified identifiers which must be always will never conflict with the user-specified identifiers which must be always
positive. positive.
See @ref page_stdevtid for the list of standard identifiers available. See @ref page_stdevtid for the list of standard identifiers available.
You can use wxID_HIGHEST to determine the number above which it is safe to You can use wxID_HIGHEST to determine the number above which it is safe to
define your own identifiers. Or, you can use identifiers below wxID_LOWEST. define your own identifiers. Or, you can use identifiers below wxID_LOWEST.
Finally, you can allocate identifiers dynamically using wxNewId() function to. Finally, you can allocate identifiers dynamically using wxNewId() function too.
If you use wxNewId() consistently in your application, you can be sure that If you use wxNewId() consistently in your application, you can be sure that
the your identifiers don't conflict accidentally. your identifiers don't conflict accidentally.
@section overview_eventhandling_custom Custom Event Summary @section overview_eventhandling_custom Custom Event Summary
@subsection overview_eventhandling_custom_general General approach @subsection overview_eventhandling_custom_general General approach
Since version 2.2.x of wxWidgets, each event type is identified by ID which Since version 2.2.x of wxWidgets, each event type is identified by an ID
is given to the event type @e at runtime which makes it possible to add given to the event type @e at runtime that makes it possible to add
new event types to the library or application without risking ID clashes new event types to the library or application without risking ID clashes
(two different event types mistakingly getting the same event ID). (two different event types mistakingly getting the same event ID).
This event type ID is stored in a struct of type <b>const wxEventType</b>. This event type ID is stored in a struct of type <b>const wxEventType</b>.
In order to define a new event type, there are principally two choices. In order to define a new event type, there are principally two choices.
One is to define a entirely new event class (typically deriving from One is to define an entirely new event class (typically deriving from
wxEvent or wxCommandEvent). wxEvent or wxCommandEvent).
The other is to use the existing event classes and give them an new event The other is to use the existing event classes and give them a new event
type. You'll have to define and declare a new event type using either way, type. You'll have to define and declare a new event type either way
and this is done using the following macros: using the following macros:
@code @code
// in the header of the source file // in the header of the source file
@@ -577,7 +577,7 @@ defining and working with the custom event types.
@subsection overview_eventhandling_custom_existing Using Existing Event Classes @subsection overview_eventhandling_custom_existing Using Existing Event Classes
If you just want to use a wxCommandEvent with a new event type, you can then use If you just want to use a wxCommandEvent with a new event type, use
one of the generic event table macros listed below, without having to define a one of the generic event table macros listed below, without having to define a
new event class yourself. This also has the advantage that you won't have to define a new event class yourself. This also has the advantage that you won't have to define a
new wxEvent::Clone() method for posting events between threads etc. new wxEvent::Clone() method for posting events between threads etc.
@@ -719,11 +719,11 @@ For the full list of event classes, please see the
@ref group_class_events "event classes group page". @ref group_class_events "event classes group page".
@todo for all controls state clearly when calling a member function results in an @todo For all controls, state clearly when calling a member function results in
event being generated and when it doesn't (possibly updating also the an event being generated and when it doesn't (possibly updating also the
'Events generated by the user vs programmatically generated events' paragraph 'Events generated by the user versus programmatically-generated events'
of the 'Event handling overview' with the list of the functions which break paragraph of the 'Event Handling Overview' with the list of the functions
that rule). that break the rule).
*/ */