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

Correct and simplify window IDs overview in the manual

Browse Source 
Explicitly mention that IDs effectively used when wxID_ANY is specified as
well as IDs returned by NewControlId() are negative and that the user IDs
should be positive to avoid clashing with such auto-generated ones.
This commit is contained in:
Vadim Zeitlin
2015-11-13 20:41:27 +01:00
parent 1f347637a6
commit b8c8cb2770
1 changed files with 9 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
docs/doxygen/overviews/windowids.h
View File

@@ -13,27 +13,16 @@
Various controls and other parts of wxWidgets need an ID. Sometimes the ID may
be directly provided by the user or have a predefined value, such as
@c wxID_OPEN. Often, however, the value of the ID is unimportant and is created
automatically by calling wxWindow::NewControlId or by passing @c wxID_ANY as
the ID of an object.
@c wxID_OPEN. Often, however, the value of the ID is unimportant and in this
case it is enough to use @c wxID_ANY as the ID of an object which tells
wxWidgets to assign an ID automatically. All such automatically-assigned IDs
are negative, so the IDs predefined in the user code should always be positive
to avoid clashes with them.
There are two ways to generate an ID. One way is to start at a negative
number, and for each new ID, return the next smallest number. This is fine for
systems that can use the full range of negative numbers for IDs, as this
provides more than enough IDs and it would take a very very long time to run
out and wrap around. However, some systems cannot use the full range of the
ID value. Windows, for example, can only use 16 bit IDs, and only has about
32000 possible automatic IDs that can be generated by wxWindow::NewControlId.
If the program runs long enough, depending on the program itself, using this
first method would cause the IDs to wrap around into the positive ID range and
cause possible clashes with any directly specified ID values.
The other way is to keep track of the IDs returned by wxWindow::NewControlId
and don't return them again until the ID is completely free and not being used
by any other objects. This will make sure that the ID values do not clash with
one another. This is accomplished by keeping a reference count for each of the
IDs that can possibly be returned by wxWindow::NewControlId. Other IDs are not
reference counted.
If you do care about the ID value but don't want to specify it as a literal in
your code, you can use wxWindow::NewControlId() to create an ID that had never
been returned by this function before and, being also negative, never conflicts
with any IDs explicitly defined in the program if the advice above is followed.
@see wxIdManager, wxWindow::NewControlId(), wxWindow::UnreserveControlId()