1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
/****************************************************************************
**
** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
** All rights reserved.
** Contact: Nokia Corporation (qt-info@nokia.com)
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:LGPL$
** Commercial Usage
** Licensees holding valid Qt Commercial licenses may use this file in
** accordance with the Qt Commercial License Agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and Nokia.
**
** GNU Lesser General Public License Usage
** Alternatively, this file may be used under the terms of the GNU Lesser
** General Public License version 2.1 as published by the Free Software
** Foundation and appearing in the file LICENSE.LGPL included in the
** packaging of this file. Please review the following information to
** ensure the GNU Lesser General Public License version 2.1 requirements
** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
**
** In addition, as a special exception, Nokia gives you certain additional
** rights. These rights are described in the Nokia Qt LGPL Exception
** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
**
** GNU General Public License Usage
** Alternatively, this file may be used under the terms of the GNU
** General Public License version 3.0 as published by the Free Software
** Foundation and appearing in the file LICENSE.GPL included in the
** packaging of this file. Please review the following information to
** ensure the GNU General Public License version 3.0 requirements will be
** met: http://www.gnu.org/copyleft/gpl.html.
**
** If you have questions regarding the use of this file, please contact
** Nokia at qt-info@nokia.com.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\example itemviews/combowidgetmapper
\title Combo Widget Mapper Example
The Delegate Widget Mapper example shows how to use a custom delegate to
map information from a model to specific widgets on a form.
\image combo-widget-mapper.png
In the \l{Simple Widget Mapper Example}, we showed the basic use of a
widget mapper to relate data exposed by a model to simple input widgets
in a user interface. However, sometimes we want to use input widgets that
expose data as choices to the user, such as QComboBox, and we need a way
to relate their input to the values stored in the model.
This example is very similar to the \l{Simple Widget Mapper Example}.
Again, we create a \c Window class with an almost identical user interface,
except that, instead of providing a spin box so that each person's age
can be entered, we provide a combo box to allow their addresses to be
classified as "Home", "Work" or "Other".
\section1 Window Class Definition
The class provides a constructor, a slot to keep the buttons up to date,
and a private function to set up the model:
\snippet examples/itemviews/combowidgetmapper/window.h Window definition
In addition to the QDataWidgetMapper object and the controls used to make
up the user interface, we use a QStandardItemModel to hold our data and
a QStringListModel to hold information about the types of address that
can be applied to each person's data.
\section1 Window Class Implementation
The constructor of the \c Window class can be explained in three parts.
In the first part, we set up the widgets used for the user interface:
\snippet examples/itemviews/combowidgetmapper/window.cpp Set up widgets
Note that we set up the mapping the combo box in the same way as for other
widgets, but that we apply its own model to it so that it will display
data from its own model, the \c typeModel, rather than from the model
containing data about each person.
Next, we set up the widget mapper, relating each input widget to a column
in the model specified by the call to \l{QDataWidgetMapper::}{setModel()}:
\snippet examples/itemviews/combowidgetmapper/window.cpp Set up the mapper
For the combo box, we pass an extra argument to tell the widget mapper
which property to relate to values from the model. As a result, the user
is able to select an item from the combo box, and the corresponding
value stored in the widget's \c currentIndex property will be stored in
the model.
\omit
However, we also set a delegate on the mapper. As with \l{Delegate Classes},
this changes the way that data is presented to the user. In this case, the
delegate acts as a proxy between the mapper and the input widgets,
translating the data into a suitable form for the combo box but not
interfering with the other input widgets. The implementation is shown later.
\endomit
The rest of the constructor is very similar to that of the
\l{Simple Widget Mapper Example}:
\snippet examples/itemviews/combowidgetmapper/window.cpp Set up connections and layouts
The model is initialized in the window's \c{setupModel()} function. Here,
we create a standard model with 5 rows and 3 columns. In each row, we
insert a name, address, and a value that indicates the type of address.
The address types are stored in a string list model.
\snippet examples/itemviews/combowidgetmapper/window.cpp Set up the model
As we insert each row into the model, like a record in a database, we
store values that correspond to items in \c typeModel for each person's
address type. When the widget mapper reads these values from the final
column of each row, it will need to use them as references to values in
\c typeModel, as shown in the following diagram. This is where the
delegate is used.
\image widgetmapper-combo-mapping.png
We show the implementation of the \c{updateButtons()} slot for
completeness:
\snippet examples/itemviews/combowidgetmapper/window.cpp Slot for updating the buttons
\omit
\section1 Delegate Class Definition and Implementation
The delegate we use to mediate interaction between the widget mapper and
the input widgets is a small QItemDelegate subclass:
\snippet examples/itemviews/combowidgetmapper/delegate.h Delegate class definition
This provides implementations of the two standard functions used to pass
data between editor widgets and the model (see the \l{Delegate Classes}
documentation for a more general description of these functions).
Since we only provide an empty implementation of the constructor, we
concentrate on the other two functions.
The \l{QItemDelegate::}{setEditorData()} implementation takes the data
referred to by the model index supplied and processes it according to
the presence of a \c currentIndex property in the editor widget:
\snippet examples/itemviews/combowidgetmapper/delegate.cpp setEditorData implementation
If, like QComboBox, the editor widget has this property, it is set using
the value from the model. Since we are passing around QVariant values,
the strings stored in the model are automatically converted to the integer
values needed for the \c currentIndex property.
As a result, instead of showing "0", "1" or "2" in the combo box, one of
its predefined set of items is shown. We call QItemDelegate::setEditorData()
for widgets without the \c currentIndex property.
The \l{QItemDelegate::}{setModelData()} implementation performs the reverse
process, taking the value stored in the widget's \c currentIndex property
and storing it back in the model:
\snippet examples/itemviews/combowidgetmapper/delegate.cpp setModelData implementation
\endomit
\section1 Summary and Further Reading
The use of a separate model for the combo box provides a menu of choices
that are separate from the data stored in the main model. Using a named
mapping that relates the combo box's \c currentIndex property to a column
in the model effectively allows us to store a look-up value in the model.
However, when reading the model outside the context of the widget mapper,
we need to know about the \c typeModel to make sense of these look-up
values. It would be useful to be able to store both the data and the
choices held by the \c typeModel in one place.
This is covered by the \l{SQL Widget Mapper Example}.
*/
|
