]>
Commit | Line | Data |
---|---|---|
200fed6c VS |
1 | \chapter{Property sheet classes}\label{proplist} |
2 | ||
3 | \section{Introduction}\label{proplistintro} | |
4 | ||
5 | The Property Sheet Classes help the programmer to specify complex dialogs and | |
6 | their relationship with their associated data. By specifying data as a | |
7 | wxPropertySheet containing wxProperty objects, the programmer can use | |
8 | a range of available or custom wxPropertyView classes to allow the user to | |
9 | edit this data. Classes derived from wxPropertyView act as mediators between the | |
10 | wxPropertySheet and the actual window (and associated panel items). | |
11 | ||
12 | For example, the wxPropertyListView is a kind of wxPropertyView which displays | |
13 | data in a Visual Basic-style property list (see \helpref{the next section}{proplistappearance} for | |
14 | screen shots). This is a listbox containing names and values, with | |
15 | an edit control and other optional controls via which the user edits the selected | |
16 | data item. | |
17 | ||
18 | wxPropertyFormView is another kind of wxPropertyView which mediates between | |
19 | the data and a panel or dialog box which has already been created. This makes it a contender for | |
20 | the replacement of wxForm, since programmer-controlled layout is going to be much more | |
21 | satisfactory. If automatic layout is desired, then wxPropertyListView could be used instead. | |
22 | ||
23 | The main intention of this class library was to provide property {\it list} behaviour, but | |
24 | it has been generalised as much as possible so that the concept of a property sheet and its viewers | |
25 | can reduce programming effort in a range of user interface tasks. | |
26 | ||
27 | For further details on the classes and how they are used, please see \helpref{Property classes overview}{proplistpropertyoverview}. | |
28 | ||
29 | \subsection{The appearance and behaviour of a property list view}\label{proplistappearance} | |
30 | ||
31 | The property list, as seen in an increasing number of development tools | |
32 | such as Visual Basic and Delphi, is a convenient and compact method for | |
33 | displaying and editing a number of items without the need for one | |
34 | control per item, and without the need for designing a special form. The | |
35 | controls are as follows: | |
36 | ||
37 | \begin{itemize}\itemsep=0pt | |
38 | \item A listbox showing the properties and their current values, which has double-click | |
39 | properties dependent on the nature of the current property; | |
40 | \item a text editing area at the top of the display, allowing the user to edit | |
41 | the currently selected property if appropriate; | |
42 | \item `confirm' and `cancel' buttons to confirm or cancel an edit (for the property, not the | |
43 | whole sheet); | |
44 | \item an optional list that appears when the user can make a choice from several known possible values; | |
45 | \item a small Edit button to invoke `detailed editing' (perhaps showing or hiding the above value list, or | |
46 | maybe invoking a common dialog); | |
47 | \item optional OK/Close, Cancel and Help buttons for the whole dialog. | |
48 | \end{itemize} | |
49 | ||
50 | The concept of `detailed editing' versus quick editing gives the user a choice | |
51 | of editing mode, so novice and expert behaviour can be catered for, or the user can just | |
52 | use what he feels comfortable with. | |
53 | ||
54 | Behaviour alters depending on the kind of property being edited. For example, a boolean value has | |
55 | the following behaviour: | |
56 | ||
57 | \begin{itemize}\itemsep=0pt | |
58 | \item Double-clicking on the item toggles between TRUE and FALSE. | |
59 | \item Showing the value list enables the user to select TRUE or FALSE. | |
60 | \item The user may be able to type in the word TRUE or FALSE, or the edit control | |
61 | may be read-only to disallow this since it is error-prone. | |
62 | \end{itemize} | |
63 | ||
64 | A list of strings may pop up a dialog for editing them, a simple string just allows text editing, | |
65 | double-clicking a colour property may show a colour selector, double-clicking on a filename property may | |
66 | show a file selector (in addition to being able to type in the name in the edit control), etc. | |
67 | ||
68 | Note that the `type' of property, such as string or integer, does not | |
69 | necessarily determine the behaviour of the property. The programmer has | |
70 | to be able to specify different behaviours for the same type, depending | |
71 | on the meaning of the property. For example, a colour and a filename may | |
72 | both be strings, but their editing behaviour should be different. This | |
73 | is why objects of type wxPropertyValidator need to be used, to define | |
74 | behaviour for a given class of properties or even specific property | |
75 | name. Objects of class wxPropertyView contain a list of property | |
76 | registries, which enable reuse of bunches of these validators in | |
77 | different circumstances. Or a wxProperty can be explicitly set to use a | |
78 | particular validator object. | |
79 | ||
80 | The following screen shot of the property classes test program shows the | |
81 | user editing a string, which is constrained to be one of three possible | |
82 | values. | |
83 | ||
84 | \helponly{\image{}{prop1.bmp}} | |
85 | ||
86 | The second picture shows the user having entered a integer that | |
87 | was outside the range specified to the validator. Note that in this picture, | |
88 | the value list is hidden because it is not used when editing an integer. | |
89 | ||
90 | \helponly{\image{}{prop2.bmp}} | |
91 | ||
92 | \section{Headers}\label{proplistfiles} | |
93 | ||
94 | The property class library comprises the following files: | |
95 | ||
96 | \begin{itemize}\itemsep=0pt | |
97 | \item prop.h: base property class header | |
98 | \item proplist.h: wxPropertyListView and associated classes | |
99 | \item propform.h: wxPropertyListView and associated classes | |
100 | \end{itemize} | |
101 | ||
200fed6c VS |
102 | \section{Topic overviews}\label{proplistoverviews} |
103 | ||
104 | This chapter contains a selection of topic overviews. | |
105 | ||
106 | \subsection{Property classes overview}\label{proplistpropertyoverview} | |
107 | ||
108 | The property classes help a programmer to express relationships between | |
109 | data and physical windows, in particular: | |
110 | ||
111 | \begin{itemize}\itemsep=0pt | |
112 | \item the transfer of data to and from the physical controls; | |
113 | \item the behaviour of various controls and custom windows for particular | |
114 | types of data; | |
115 | \item the validation of data, notifying the user when incorrect data is entered, | |
116 | or even better, constraining the input so only valid data can be entered. | |
117 | \end{itemize} | |
118 | ||
119 | With a consistent framework, the programmer should be able to use existing | |
120 | components and design new ones in a principled manner, to solve many data entry | |
121 | requirements. | |
122 | ||
123 | Each datum is represented in a \helpref{wxProperty}{wxproperty}, which has a name and a value. | |
124 | Various C++ types are permitted in the value of a property, and the property can store a pointer | |
125 | to the data instead of a copy of the data. A \helpref{wxPropertySheet}{wxpropertysheet} represents a number of these properties. | |
126 | ||
127 | These two classes are independent from the way in which the data is visually manipulated. To | |
128 | mediate between property sheets and windows, the abstract class \helpref{wxPropertyView}{wxpropertyview} is | |
129 | available for programmers to derive new kinds of view. One kind of view that is available is the \helpref{wxPropertyListView}{wxpropertylistview}, | |
130 | which displays the data in a Visual Basic-style list, with a small number of controls for editing | |
131 | the currently selected property. Another is \helpref{wxPropertyFormView}{wxpropertyformview} which | |
132 | mediates between an existing dialog or panel and the property sheet. | |
133 | ||
134 | The hard work of mediation is actually performed by validators, which are instances of classes | |
135 | derived from \helpref{wxPropertyValidator}{wxpropertyvalidator}. A validator is associated with | |
136 | a particular property and is responsible for | |
137 | responding to user interface events, and displaying, updating and checking the property value. | |
138 | Because a validator's behaviour depends largely on the kind of view being used, there has to be | |
139 | a separate hierarchy of validators for each class of view. So for wxPropertyListView, there is | |
140 | an abstract class \helpref{wxPropertyListValidator}{wxpropertylistvalidator} from which concrete | |
141 | classes are derived, such as \helpref{wxRealListValidator}{wxreallistvalidator} and | |
142 | \rtfsp\helpref{wxStringListValidator}{wxstringlistvalidator}. | |
143 | ||
144 | A validator can be explicitly set for a property, so there is no doubt which validator | |
145 | should be used to edit that property. However, it is also possible to define a registry | |
146 | of validators, and have the validator chosen on the basis of the {\it role} of the property. | |
147 | So a property with a ``filename" role would match the ``filename" validator, which pops | |
148 | up a file selector when the user double clicks on the property. | |
149 | ||
150 | You don't have to define your own frame or window classes: there are some predefined | |
151 | that will work with the property list view. See \helpref{Window classes}{proplistwindowclasses} for | |
152 | further details. | |
153 | ||
154 | \subsubsection{Example 1: Property list view} | |
155 | ||
156 | The following code fragment shows the essentials of creating a registry of | |
157 | standard validators, a property sheet containing some properties, and | |
158 | a property list view and dialog or frame. RegisterValidators will be | |
159 | called on program start, and PropertySheetTest is called in response to a | |
160 | menu command. | |
161 | ||
162 | Note how some properties are created with an explicit reference to | |
163 | a validator, and others are provided with a ``role'' which can be matched | |
164 | against a validator in the registry. | |
165 | ||
166 | The interface generated by this test program is shown in the section \helpref{Appearance and | |
167 | behaviour of a property list view}{proplistappearance}. | |
168 | ||
169 | \begin{verbatim} | |
170 | void RegisterValidators(void) | |
171 | { | |
172 | myListValidatorRegistry.RegisterValidator((wxString)"real", new wxRealListValidator); | |
173 | myListValidatorRegistry.RegisterValidator((wxString)"string", new wxStringListValidator); | |
174 | myListValidatorRegistry.RegisterValidator((wxString)"integer", new wxIntegerListValidator); | |
175 | myListValidatorRegistry.RegisterValidator((wxString)"bool", new wxBoolListValidator); | |
176 | } | |
177 | ||
178 | void PropertyListTest(Bool useDialog) | |
179 | { | |
180 | wxPropertySheet *sheet = new wxPropertySheet; | |
181 | ||
182 | sheet->AddProperty(new wxProperty("fred", 1.0, "real")); | |
183 | sheet->AddProperty(new wxProperty("tough choice", (Bool)TRUE, "bool")); | |
184 | sheet->AddProperty(new wxProperty("ian", (long)45, "integer", new wxIntegerListValidator(-50, 50))); | |
185 | sheet->AddProperty(new wxProperty("bill", 25.0, "real", new wxRealListValidator(0.0, 100.0))); | |
186 | sheet->AddProperty(new wxProperty("julian", "one", "string")); | |
187 | sheet->AddProperty(new wxProperty("bitmap", "none", "string", new wxFilenameListValidator("Select a bitmap file", "*.bmp"))); | |
188 | wxStringList *strings = new wxStringList("one", "two", "three", NULL); | |
189 | sheet->AddProperty(new wxProperty("constrained", "one", "string", new wxStringListValidator(strings))); | |
190 | ||
191 | wxPropertyListView *view = | |
192 | new wxPropertyListView(NULL, | |
193 | wxPROP_BUTTON_CHECK_CROSS|wxPROP_DYNAMIC_VALUE_FIELD|wxPROP_PULLDOWN); | |
194 | ||
195 | wxDialogBox *propDialog = NULL; | |
196 | wxPropertyListFrame *propFrame = NULL; | |
197 | if (useDialog) | |
198 | { | |
199 | propDialog = new wxPropertyListDialog(view, NULL, "Property Sheet Test", TRUE, -1, -1, 400, 500); | |
200 | } | |
201 | else | |
202 | { | |
203 | propFrame = new wxPropertyListFrame(view, NULL, "Property Sheet Test", -1, -1, 400, 500); | |
204 | } | |
205 | ||
206 | view->AddRegistry(&myListValidatorRegistry); | |
207 | ||
208 | if (useDialog) | |
209 | { | |
210 | view->ShowView(sheet, propDialog); | |
211 | propDialog->Centre(wxBOTH); | |
212 | propDialog->Show(TRUE); | |
213 | } | |
214 | else | |
215 | { | |
216 | propFrame->Initialize(); | |
217 | view->ShowView(sheet, propFrame->GetPropertyPanel()); | |
218 | propFrame->Centre(wxBOTH); | |
219 | propFrame->Show(TRUE); | |
220 | } | |
221 | } | |
222 | \end{verbatim} | |
223 | ||
224 | \subsubsection{Example 2: Property form view} | |
225 | ||
226 | This example is similar to Example 1, but uses a property form view to | |
227 | edit a property sheet using a predefined dialog box. | |
228 | ||
229 | \begin{verbatim} | |
230 | void RegisterValidators(void) | |
231 | { | |
232 | myFormValidatorRegistry.RegisterValidator((wxString)"real", new wxRealFormValidator); | |
233 | myFormValidatorRegistry.RegisterValidator((wxString)"string", new wxStringFormValidator); | |
234 | myFormValidatorRegistry.RegisterValidator((wxString)"integer", new wxIntegerFormValidator); | |
235 | myFormValidatorRegistry.RegisterValidator((wxString)"bool", new wxBoolFormValidator); | |
236 | } | |
237 | ||
238 | void PropertyFormTest(Bool useDialog) | |
239 | { | |
240 | wxPropertySheet *sheet = new wxPropertySheet; | |
241 | ||
242 | sheet->AddProperty(new wxProperty("fred", 25.0, "real", new wxRealFormValidator(0.0, 100.0))); | |
243 | sheet->AddProperty(new wxProperty("tough choice", (Bool)TRUE, "bool")); | |
244 | sheet->AddProperty(new wxProperty("ian", (long)45, "integer", new wxIntegerFormValidator(-50, 50))); | |
245 | sheet->AddProperty(new wxProperty("julian", "one", "string")); | |
246 | wxStringList *strings = new wxStringList("one", "two", "three", NULL); | |
247 | sheet->AddProperty(new wxProperty("constrained", "one", "string", new wxStringFormValidator(strings))); | |
248 | ||
249 | wxPropertyFormView *view = new wxPropertyFormView(NULL); | |
250 | ||
251 | wxDialogBox *propDialog = NULL; | |
252 | wxPropertyFormFrame *propFrame = NULL; | |
253 | if (useDialog) | |
254 | { | |
255 | propDialog = new wxPropertyFormDialog(view, NULL, "Property Form Test", TRUE, -1, -1, 400, 300); | |
256 | } | |
257 | else | |
258 | { | |
259 | propFrame = new wxPropertyFormFrame(view, NULL, "Property Form Test", -1, -1, 400, 300); | |
260 | propFrame->Initialize(); | |
261 | } | |
262 | ||
263 | wxPanel *panel = propDialog ? propDialog : propFrame->GetPropertyPanel(); | |
264 | panel->SetLabelPosition(wxVERTICAL); | |
265 | ||
266 | // Add items to the panel | |
267 | ||
268 | (void) new wxButton(panel, (wxFunction)NULL, "OK", -1, -1, -1, -1, 0, "ok"); | |
269 | (void) new wxButton(panel, (wxFunction)NULL, "Cancel", -1, -1, 80, -1, 0, "cancel"); | |
270 | (void) new wxButton(panel, (wxFunction)NULL, "Update", -1, -1, 80, -1, 0, "update"); | |
271 | (void) new wxButton(panel, (wxFunction)NULL, "Revert", -1, -1, -1, -1, 0, "revert"); | |
272 | panel->NewLine(); | |
273 | ||
274 | // The name of this text item matches the "fred" property | |
275 | (void) new wxText(panel, (wxFunction)NULL, "Fred", "", -1, -1, 90, -1, 0, "fred"); | |
276 | (void) new wxCheckBox(panel, (wxFunction)NULL, "Yes or no", -1, -1, -1, -1, 0, "tough choice"); | |
277 | (void) new wxSlider(panel, (wxFunction)NULL, "Sliding scale", 0, -50, 50, 100, -1, -1, wxHORIZONTAL, "ian"); | |
278 | panel->NewLine(); | |
279 | (void) new wxListBox(panel, (wxFunction)NULL, "Constrained", wxSINGLE, -1, -1, 100, 90, 0, NULL, 0, "constrained"); | |
280 | ||
281 | view->AddRegistry(&myFormValidatorRegistry); | |
282 | ||
283 | if (useDialog) | |
284 | { | |
285 | view->ShowView(sheet, propDialog); | |
286 | view->AssociateNames(); | |
287 | view->TransferToDialog(); | |
288 | propDialog->Centre(wxBOTH); | |
289 | propDialog->Show(TRUE); | |
290 | } | |
291 | else | |
292 | { | |
293 | view->ShowView(sheet, propFrame->GetPropertyPanel()); | |
294 | view->AssociateNames(); | |
295 | view->TransferToDialog(); | |
296 | propFrame->Centre(wxBOTH); | |
297 | propFrame->Show(TRUE); | |
298 | } | |
299 | } | |
300 | \end{verbatim} | |
301 | ||
302 | \subsection{Validator classes overview}\label{proplistvalidatoroverview} | |
303 | ||
304 | Classes: \helpref{Validator classes}{proplistvalidatorclasses} | |
305 | ||
306 | The validator classes provide functionality for mediating between a wxProperty and | |
307 | the actual display. There is a separate family of validator classes for each | |
308 | class of view, since the differences in user interface for these views implies | |
309 | that little common functionality can be shared amongst validators. | |
310 | ||
311 | ||
312 | ||
313 | \subsubsection{wxPropertyValidator overview}\label{wxpropertyvalidatoroverview} | |
314 | ||
315 | Class: \helpref{wxPropertyValidator}{wxpropertyvalidator} | |
316 | ||
317 | This class is the root of all property validator classes. It contains a small | |
318 | amount of common functionality, including functions to convert between | |
319 | strings and C++ values. | |
320 | ||
321 | A validator is notionally an object which sits between a property and its displayed | |
322 | value, and checks that the value the user enters is correct, giving an error message | |
323 | if the validation fails. In fact, the validator does more than that, and is akin to | |
324 | a view class but at a finer level of detail. It is also responsible for | |
325 | loading the dialog box control with the value from the property, putting it back | |
326 | into the property, preparing special controls for editing the value, and | |
327 | may even invoke special dialogs for editing the value in a convenient way. | |
328 | ||
329 | In a property list dialog, there is quite a lot of scope for supplying custom dialogs, | |
330 | such as file or colour selectors. For a form dialog, there is less scope because | |
331 | there is no concept of `detailed editing' of a value: one control is associated with | |
332 | one property, and there is no provision for invoking further dialogs. The reader | |
333 | may like to work out how the form view could be extended to provide some of the | |
334 | functionality of the property list! | |
335 | ||
f6bcfd97 | 336 | Validator objects may be associated explicitly with a wxProperty, or they may be |
200fed6c VS |
337 | indirectly associated by virtue of a property `kind' that matches validators having |
338 | that kind. In the latter case, such validators are stored in a validator registry | |
339 | which is passed to the view before the dialog is shown. If the validator takes | |
340 | arguments, such as minimum and maximum values in the case of a wxIntegerListValidator, | |
341 | then the validator must be associated explicitly with the property. The validator | |
342 | will be deleted when the property is deleted. | |
343 | ||
344 | \subsubsection{wxPropertyListValidator overview}\label{wxpropertylistvalidatoroverview} | |
345 | ||
346 | Class: \helpref{wxPropertyListValidator}{wxpropertylistvalidator} | |
347 | ||
348 | This class is the abstract base class for property list view validators. | |
349 | The list view acts upon a user interface containing a list of properties, | |
350 | a text item for direct property value editing, confirm/cancel buttons for the value, | |
351 | a pulldown list for making a choice between values, and OK/Cancel/Help buttons | |
352 | for the dialog (see \helpref{property list appearance}{proplistappearance}). | |
353 | ||
354 | By overriding virtual functions, the programmer can create custom | |
355 | behaviour for different kinds of property. Custom behaviour can use just the | |
356 | available controls on the property list dialog, or the validator can | |
357 | invoke custom editors with quite different controls, which pop up in | |
358 | `detailed editing' mode. | |
359 | ||
360 | See the detailed class documentation for the members you should override | |
361 | to give your validator appropriate behaviour. | |
362 | ||
363 | \subsubsection{wxPropertyFormValidator overview}\label{wxpropertyformvalidatoroverview} | |
364 | ||
365 | This class is the abstract base class for property form view validators. | |
366 | The form view acts upon an existing dialog box or panel, where either the | |
367 | panel item names correspond to property names, or the programmer has explicitly | |
368 | associated the panel item with the property. | |
369 | ||
370 | By overriding virtual functions, the programmer determines how | |
371 | values are displayed or retrieved, and the checking that the validator does. | |
372 | ||
373 | See the detailed class documentation for the members you should override | |
374 | to give your validator appropriate behaviour. | |
375 | ||
376 | \subsection{View classes overview}\label{proplistviewoverview} | |
377 | ||
378 | Classes: \helpref{View classes}{proplistviewclasses} | |
379 | ||
380 | An instance of a view class relates a property sheet with an actual window. | |
381 | Currently, there are two classes of view: wxPropertyListView and wxPropertyFormView. | |
382 | ||
383 | \subsubsection{wxPropertyView overview}\label{wxpropertyviewoverview} | |
384 | ||
385 | Class: \helpref{wxPropertyView}{wxpropertyview} | |
386 | ||
387 | This is the abstract base class for property views. | |
388 | ||
389 | \subsubsection{wxPropertyListView overview}\label{wxpropertylistviewoverview} | |
390 | ||
391 | Class: \helpref{wxPropertyListView}{wxpropertylistview} | |
392 | ||
393 | The property list view defines the relationship between a property sheet and | |
394 | a property list dialog or panel. It manages user interface events such as | |
395 | clicking on a property, pressing return in the text edit field, and clicking | |
396 | on Confirm or Cancel. These events cause member functions of the | |
397 | class to be called, and these in turn may call member functions of | |
398 | the appropriate validator to be called, to prepare controls, check the property value, | |
399 | invoke detailed editing, etc. | |
400 | ||
401 | \subsubsection{wxPropertyFormView overview}\label{wxpropertyformviewoverview} | |
402 | ||
403 | Class: \helpref{wxPropertyFormView}{wxpropertyformview} | |
404 | ||
405 | The property form view manages the relationship between a property sheet | |
406 | and an existing dialog or panel. | |
407 | ||
408 | You must first create a panel or dialog box for the view to work on. | |
409 | The panel should contain panel items with names that correspond to | |
410 | properties in your property sheet; or you can explicitly set the | |
411 | panel item for each property. | |
412 | ||
413 | Apart from any custom panel items that you wish to control independently | |
414 | of the property-editing items, wxPropertyFormView takes over the | |
415 | processing of item events. It can also control normal dialog behaviour such | |
416 | as OK, Cancel, so you should also create some standard buttons that the property view | |
417 | can recognise. Just create the buttons with standard names and the view | |
418 | will do the rest. The following button names are recognised: | |
419 | ||
420 | \begin{itemize}\itemsep=0pt | |
421 | \item {\bf ok}: indicates the OK button. Calls wxPropertyFormView::OnOk. By default, | |
422 | checks and updates the form values, closes and deletes the frame or dialog, then deletes the view. | |
423 | \item {\bf cancel}: indicates the Cancel button. Calls wxPropertyFormView::OnCancel. By default, | |
424 | closes and deletes the frame or dialog, then deletes the view. | |
425 | \item {\bf help}: indicates the Help button. Calls wxPropertyFormView::OnHelp. This needs | |
426 | to be overridden by the application for anything interesting to happen. | |
427 | \item {\bf revert}: indicates the Revert button. Calls wxPropertyFormView::OnRevert, | |
428 | which by default transfers the wxProperty values to the panel items (in effect | |
429 | undoing any unsaved changes in the items). | |
430 | \item {\bf update}: indicates the Revert button. Calls wxPropertyFormView::OnUpdate, which | |
431 | by defaults transfers the displayed values to the wxProperty objects. | |
432 | \end{itemize} | |
433 | ||
434 | \subsection{wxPropertySheet overview}\label{wxpropertysheetoverview} | |
435 | ||
436 | Classes: \helpref{wxPropertySheet}{wxpropertysheet}, \helpref{wxProperty}{wxproperty}, \helpref{wxPropertyValue}{wxpropertyvalue} | |
437 | ||
438 | A property sheet defines zero or more properties. This is a bit like an explicit representation of | |
439 | a C++ object. wxProperty objects can have values which are pointers to C++ values, or they | |
440 | can allocate their own storage for values. | |
441 | ||
442 | Because the property sheet representation is explicit and can be manipulated by | |
443 | a program, it is a convenient form to be used for a variety of | |
444 | editing purposes. wxPropertyListView and wxPropertyFormView are two classes that | |
445 | specify the relationship between a property sheet and a user interface. You could imagine | |
446 | other uses for wxPropertySheet, for example to generate a form-like user interface without | |
447 | the need for GUI programming. Or for storing the names and values of command-line switches, with the | |
448 | option to subsequently edit these values using a wxPropertyListView. | |
449 | ||
450 | A typical use for a property sheet is to represent values of an object | |
451 | which are only implicit in the current representation of it. For | |
452 | example, in Visual Basic and similar programming environments, you can | |
453 | `edit a button', or rather, edit the button's properties. One of the | |
454 | properties you can edit is {\it width} - but there is no explicit | |
455 | representation of width in a wxWindows button; instead, you call SetSize | |
f6bcfd97 | 456 | and GetSize members. To translate this into a consistent, |
200fed6c VS |
457 | property-oriented scheme, we could derive a new class |
458 | wxButtonWithProperties, which has two new functions: SetProperty and | |
459 | GetProperty. SetProperty accepts a property name and a value, and calls | |
460 | an appropriate function for the property that is being passed. | |
461 | GetProperty accepts a property name, returning a property value. So | |
462 | instead of having to use the usual arbitrary set of C++ member functions | |
463 | to set or access attributes of a window, programmer deals merely with | |
464 | SetValue/GetValue, and property names and values. | |
465 | We now have a single point at which we can modify or query an object by specifying | |
466 | names and values at run-time. (The implementation of SetProperty and GetProperty | |
467 | is probably quite messy and involves a large if-then-else statement to | |
468 | test the property name and act accordingly.) | |
469 | ||
470 | When the user invokes the property editor for a wxButtonWithProperties, the system | |
471 | creates a wxPropertySheet with `imaginary' properties such as width, height, font size | |
472 | and so on. For each property, wxButtonWithProperties::GetProperty is called, and the result is | |
473 | passed to the corresponding wxProperty. The wxPropertySheet is passed to a wxPropertyListView | |
474 | as described elsewhere, and the user edits away. When the user has finished editing, the system calls | |
475 | wxButtonWithProperties::SetProperty to transfer the wxProperty value back into the button | |
476 | by way of an appropriate call, wxWindow::SetSize in the case of width and height properties. | |
477 | ||
200fed6c VS |
478 | \section{Classes by category}\label{proplistclassesbycat} |
479 | ||
480 | A classification of property sheet classes by category. | |
481 | ||
482 | \subsection{Data classes} | |
483 | ||
484 | \begin{itemize}\itemsep=0pt | |
485 | \item \helpref{wxProperty}{wxproperty} | |
486 | \item \helpref{wxPropertyValue}{wxpropertyvalue} | |
487 | \item \helpref{wxPropertySheet}{wxpropertysheet} | |
488 | \end{itemize} | |
489 | ||
200fed6c VS |
490 | \subsection{Validator classes}\label{proplistvalidatorclasses} |
491 | ||
492 | Validators check that the values the user has entered for a property are | |
493 | valid. They can also define specific ways of entering data, such as a | |
494 | file selector for a filename, and they are responsible for transferring | |
495 | values between the wxProperty and the physical display. | |
496 | ||
497 | Base classes: | |
498 | ||
499 | \begin{itemize}\itemsep=0pt | |
500 | \item \helpref{wxPropertyValidator}{wxproperty} | |
501 | \item \helpref{wxPropertyListValidator}{wxpropertylistvalidator} | |
502 | \item \helpref{wxPropertyFormValidator}{wxpropertyformvalidator} | |
503 | \end{itemize} | |
504 | ||
505 | List view validators: | |
506 | ||
507 | \begin{itemize}\itemsep=0pt | |
508 | \item \helpref{wxBoolListValidator}{wxboollistvalidator} | |
509 | \item \helpref{wxFilenameListValidator}{wxfilenamelistvalidator} | |
510 | \item \helpref{wxIntegerListValidator}{wxintegerlistvalidator} | |
511 | \item \helpref{wxListOfStringsListValidator}{wxlistofstringslistvalidator} | |
512 | \item \helpref{wxRealListValidator}{wxreallistvalidator} | |
513 | \item \helpref{wxStringListValidator}{wxstringlistvalidator} | |
514 | \end{itemize} | |
515 | ||
516 | Form view validators: | |
517 | ||
518 | \begin{itemize}\itemsep=0pt | |
519 | \item \helpref{wxBoolFormValidator}{wxboolformvalidator} | |
520 | \item \helpref{wxIntegerFormValidator}{wxintegerformvalidator} | |
521 | \item \helpref{wxRealFormValidator}{wxrealformvalidator} | |
522 | \item \helpref{wxStringFormValidator}{wxstringformvalidator} | |
523 | \end{itemize} | |
524 | ||
525 | \subsection{View classes}\label{proplistviewclasses} | |
526 | ||
527 | View classes mediate between a property sheet and a physical window. | |
528 | ||
529 | \begin{itemize}\itemsep=0pt | |
530 | \item \helpref{wxPropertyView}{wxpropertyview} | |
531 | \item \helpref{wxPropertyListView}{wxpropertylistview} | |
532 | \item \helpref{wxPropertyFormView}{wxpropertyformview} | |
533 | \end{itemize} | |
534 | ||
535 | \subsection{Window classes}\label{proplistwindowclasses} | |
536 | ||
537 | The class library defines some window classes that can be used as-is with a suitable | |
538 | view class and property sheet. | |
539 | ||
540 | \begin{itemize}\itemsep=0pt | |
541 | \item \helpref{wxPropertyFormFrame}{wxpropertyformframe} | |
542 | \item \helpref{wxPropertyFormDialog}{wxpropertyformdialog} | |
543 | \item \helpref{wxPropertyFormPanel}{wxpropertyformpanel} | |
544 | \item \helpref{wxPropertyListFrame}{wxpropertylistframe} | |
545 | \item \helpref{wxPropertyListDialog}{wxpropertylistdialog} | |
546 | \item \helpref{wxPropertyListPanel}{wxpropertylistpanel} | |
547 | \end{itemize} | |
548 | ||
549 | \subsection{Registry classes} | |
550 | ||
551 | A validator registry is a list of validators that can be applied to properties in a property sheet. | |
552 | There may be one or more registries per property view. | |
553 | ||
554 | \begin{itemize}\itemsep=0pt | |
555 | \item \helpref{wxPropertyValidatorRegistry}{wxpropertyvalidatorregistry} | |
556 | \end{itemize} |