]>
Commit | Line | Data |
---|---|---|
1 | ///////////////////////////////////////////////////////////////////////////// | |
2 | // Name: windowids.h | |
3 | // Purpose: topic overview | |
4 | // Author: wxWidgets team | |
5 | // RCS-ID: $Id$ | |
6 | // Licence: wxWindows licence | |
7 | ///////////////////////////////////////////////////////////////////////////// | |
8 | ||
9 | /** | |
10 | ||
11 | @page overview_windowids Window IDs | |
12 | ||
13 | @tableofcontents | |
14 | ||
15 | Various controls and other parts of wxWidgets need an ID. Sometimes the ID may | |
16 | be directly provided by the user or have a predefined value, such as | |
17 | @c wxID_OPEN. Often, however, the value of the ID is unimportant and is created | |
18 | automatically by calling wxWindow::NewControlId or by passing @c wxID_ANY as | |
19 | the ID of an object. | |
20 | ||
21 | There are two ways to generate an ID. One way is to start at a negative | |
22 | number, and for each new ID, return the next smallest number. This is fine for | |
23 | systems that can use the full range of negative numbers for IDs, as this | |
24 | provides more than enough IDs and it would take a very very long time to run | |
25 | out and wrap around. However, some systems cannot use the full range of the | |
26 | ID value. Windows, for example, can only use 16 bit IDs, and only has about | |
27 | 32000 possible automatic IDs that can be generated by wxWindow::NewControlId. | |
28 | If the program runs long enough, depending on the program itself, using this | |
29 | first method would cause the IDs to wrap around into the positive ID range and | |
30 | cause possible clashes with any directly specified ID values. | |
31 | ||
32 | The other way is to keep track of the IDs returned by wxWindow::NewControlId | |
33 | and don't return them again until the ID is completely free and not being used | |
34 | by any other objects. This will make sure that the ID values do not clash with | |
35 | one another. This is accomplished by keeping a reference count for each of the | |
36 | IDs that can possibly be returned by wxWindow::NewControlId. Other IDs are not | |
37 | reference counted. | |
38 | ||
39 | @see wxIdManager, wxWindow::NewControlId(), wxWindow::UnreserveControlId() | |
40 | ||
41 | ||
42 | @section overview_windowids_type Data Types | |
43 | ||
44 | A wxWindowID is just the integer type for a window ID. It should be used | |
45 | almost everywhere. To help keep track of the count for the automatically | |
46 | generated IDs, a new type, wxWindowIDRef exists, that can take the place of | |
47 | wxWindowID where needed. When an ID is first created, it is marked as reserved. | |
48 | When assigning it to a wxWindowIDRef, the usage count of the ID is increased, | |
49 | or set to 1 if it is currently reserved. Assigning the same ID to several | |
50 | wxWindowIDRefs will keep track of the count. As the wxWindowIDRef gets | |
51 | destroyed or its value changes, it will decrease the count of the used ID. When | |
52 | there are no more wxWindowIDRef types with the created ID, the ID is considered | |
53 | free and can then be used again by wxWindow::NewControlId. | |
54 | ||
55 | If a created ID is not assigned to a wxWindowIDRef, then it remains reserved | |
56 | until it is unreserved manually with wxWindow::UnreserveControlId. However, if | |
57 | it is assigned to a wxWindowIDRef, then it will be unreserved automatically and | |
58 | will be considered free when the count is 0, and should NOT be manually | |
59 | unreserved. | |
60 | ||
61 | wxWindowIDRef can store both automatic IDs from wxWindow::NewControlId and | |
62 | normal IDs. Reference counting is only done for the automatic IDs. Also, | |
63 | wxWindowIDRef has conversion operators that allow it to be treated just like a | |
64 | wxWindowID. | |
65 | ||
66 | ||
67 | @section overview_windowids_using Using wxWindowIDRef | |
68 | ||
69 | A wxWindowIDRef should be used in place of a wxWindowID where you want to make | |
70 | sure the ID is not created again by wxWindow::NewControlId at least until the | |
71 | wxWindowIDRef is destroyed, usually when the associated object is destroyed. | |
72 | This is done already for windows, menu items, and tool bar items. It should | |
73 | only be used in the main thread, as it is not thread safe. | |
74 | ||
75 | */ |