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
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.
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
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
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
may use the @c wxID_OK identifier, for example, on any number of dialogs so
long as you don't have several within the same dialog.
may use the @c wxID_OK identifier, for example, on any number of dialogs
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
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
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
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
positive.
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
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
the your identifiers don't conflict accidentally.
your identifiers don't conflict accidentally.
@section overview_eventhandling_custom Custom Event Summary
@subsection overview_eventhandling_custom_general General approach
Since version 2.2.x of wxWidgets, each event type is identified by ID which
is given to the event type @e at runtime which makes it possible to add
Since version 2.2.x of wxWidgets, each event type is identified by an ID
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
(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>.
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).
The other is to use the existing event classes and give them an new event
type. You'll have to define and declare a new event type using either way,
and this is done using the following macros:
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 either way
using the following macros:
@code
// 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
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
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.
@@ -719,11 +719,11 @@ For the full list of event classes, please see the
@ref group_class_events "event classes group page".
@todo for all controls state clearly when calling a member function results in an
event being generated and when it doesn't (possibly updating also the
'Events generated by the user vs programmatically generated events' paragraph
of the 'Event handling overview' with the list of the functions which break
that rule).
@todo For all controls, state clearly when calling a member function results in
an event being generated and when it doesn't (possibly updating also the
'Events generated by the user versus programmatically-generated events'
paragraph of the 'Event Handling Overview' with the list of the functions
that break the rule).
*/