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