Un-Mapping Mapped Network Drives Andrew Coates - dFPUG-Portal

Improving the interface
Figure 1 illustrates the new Visual Basic project.
The first order of business is addressing the first
limitation of too much functionality (yes, I know that
sounds funny). The following code is associated with the
grid control. Most of the code deals with the visual
characteristics of the grid—location and size. The most
important method is the SetDataSource Member.
Remember, in VFP, an ADO RecordSet can’t be bound to
the DataGrid control. This is how you can get around that
limitation. Pass the ADO RecordSet to the control, and
have the control do the binding for you within its
boundaries! It works like a charm.
Private Sub UserControl_Initialize()
'When the control is dropped onto the form,
'the grid must be positioned in the upper-
'left corner of the container.
With DataGrid
.Left = 0
.Top = 0
End With
End Sub
Private Sub UserControl_Resize()
'When the container is resized, we want the
'grid to also resize.
With DataGrid
.Width = ScaleWidth
.Height = ScaleHeight
End With
End Sub
'WARNING! DO NOT REMOVE OR MODIFY
'THE FOLLOWING COMMENTED LINES!
'MemberInfo=14
Public Sub SetDataSource(recordset As ADODB.recordset)
Set DataGrid.DataSource = recordset
End Sub
With this design, the services of our grid control
are very granular. Its only purpose is to accept an
ADO RecordSet and display the data. We’ll reserve the
more complicated tasks of responding to events for
another control.
The other control in the Visual Basic project consists
of one user interface element—a Label control. There’s
quite a lot of code behind this control—far too much to
Figure 1. The new Visual Basic ActiveX control project contains
two ActiveX controls.
print in its entirety. However, I’ll highlight the most
important pieces of code.
Going back to the limitations of the first design, no
public interfaces existed to make the ADO DataSource
variable. Also, all of the events in the previous design
were private. This meant that while the control within its
boundaries recognized the event, no mechanism existed
for the control to surface those events to its own interface.
This means that any application environment hosting the
control wouldn’t have the ability to have its own code
execute when those events have fired. After all, that’s
what it’s all about—having the ability to attach VFP code
to ADO events.
The first lines of code in the VB ActiveX control
are as follows:
Dim WithEvents oconn As ADODB.Connection
Dim WithEvents ors As ADODB.recordset
This provides that ability to the ActiveX control to
respond to events that each of these objects will fire. The
previous design took advantage of this ability and
attached Visual Basic code to those events. In the old
design, when an ADO connection was established, a
MessageBox dialog box appeared, stating that the ADO
connection was complete. While not very useful, it served
to illustrate how events could be trapped. Visual Basic
code is nice, but we work in VFP. We need the ability to
surface these events so that VFP code can be used.
Custom events
Remember when VFP 3.0 was released back in 1995? We
were given the ability to define our own methods and
properties. Defining events, on the other hand, was
something that wasn’t—and still isn’t—-provided. I, for
one, didn’t see the big deal in this. After all, there are
hundreds of events already defined. Why would I need
more? As you’ll see, the ability to define custom events is
a very powerful capability.
To illustrate the power of events, I’ll focus on the
MoveComplete event of the ADO RecordSet object. This
event fires whenever the record changes. This event gets
fired as a result of invoking the MoveFirst, MovePrevious,
MoveNext, or MoveLast methods. The MoveComplete
event also fires when an ADO RecordSet is first opened.
Before looking at the custom event, let’s take a look at
the code for the internal event that gets fired:
Private Sub ors_MoveComplete( _
ByVal adReason As ADODB.EventReasonEnum, _
ByVal pError As ADODB.Error, _
adStatus As ADODB.EventStatusEnum, _
ByVal pRecordset As ADODB.recordset)
RaiseEvent movecomplete(adReason, pError, _
adStatusCancel, pRecordset)
End Sub
In this code, the internal ors_RecordSet object
variable will respond to the MoveComplete event. This
code block, in turn, will fire. The code to key on is the
RaiseEvent statement. Notice that another MoveComplete
16 FoxTalk December 1998
http://www.pinpub.com