Next, we??™re going to design some classes to make this form
work. At first glance, you might think having one class tied to the data record will suffice, but
we are going to break up the functional areas when we define our classes, and we??™ll design a
class or two to help us define our wizard steps. At the end of the process, we??™ll have a flexible
wizard application that will give us the ability to change the order of the steps very easily and
even make adding a step fairly simple.
HRWizard Classes
Since some of the employee information we are collecting will be passed on to other departments
for processing, we??™ll place the data from each screen in its own class. We??™re also going to
CHAPTER 4 n USERFORMS 160
need a class to monitor the steps in the wizard. We might also consider a class to help us
populate those lists that use data from our ListMgr worksheet. Table 4-8 lists each class and
describes some of its functionality.
Table 4-8. HRWizard Application Class Modules
Class Description
cPerson Holds all personal information for the new record
cAddress Holds all address information for the new record
cEquipment Holds all equipment information for the new record
cAccess Holds all access information for the new record
cStep Holds configuration values for each step of the wizard
cStepMgr Controls the operation of the wizard and manages a collection of cStep objects
cListMgr Controls the lists that will populate the combo boxes on the UserForm
cHRData Transfers data to the database from the business objects; sends data from the
database to the business objects
The HRWizard Business Objects
We??™ll begin by designing our business objects.
Pages:
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