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

THIS.aForms[lnNewRow, 3] = loObject
RETURN
ENDPROC
PROCEDURE RemoveForm
LPARAMETERS tuParm1, tcParmType
*-- This method would allow a single form to
*-- be removed from the collection. The
*-- first parameter could be an object
*-- reference, an index position within the
*-- collection, a form name, or even a caption.
*-- When the form is removed, the array
*-- containing the collection would be
*-- adjusted. If the last form in the
*-- collection is removed, the first position
*-- in the collection array would be set to
*-- .F. to indicate an empty collection.
ENDPROC
PROCEDURE RemoveAllForms
*-- This method would allow all forms to be
*-- removed from the collection. The
*-- GetFormCount method would be used
*-- to determine the number of forms in the
*-- collection, and this method would iterate
*-- through them to call the
*-- .RemoveForm method for each.
ENDPROC
PROCEDURE GetFormRef
LPARAMETERS tuParm1, tcParmType
*-- This method returns a reference to the
*-- form indicated by the passed parameters.
*-- The parameter might be a class name, an
*-- index position within the collection,
*-- a caption, or some other form-specific
*-- property. The FindForm method would be
*-- used to find the matching form row
*-- within the collection. If there's no
*-- matching form found, NULL would be
*-- returned.
ENDPROC
ENDDEFINE
The idea behind this class definition is that the Forms
Manager would always be available to the open forms in
the application. This is often handled by making the
Forms Manager itself a member of the omnipresent
“application object.” Because the Forms Manager is
always available, the forms in the application can add
themselves to it when instantiating and remove
themselves from it during the destruction process. For
example, the following code would be placed into a base
form class’s Init() event to automate the process of adding
a new form to the collection:
oApp.oFormsManager.AddForm(THISFORM)
When the form is being closed, the following line
of code in the form’s Destroy() event would prompt
the Forms Manager to remove the closing form from
the collection:
oApp.oFormsManager.RemoveForm(THISFORM)
Obviously, the preceding example code isn’t a
complete Forms Manager solution, but it illustrates a
variety of reasons that a Forms Manager’s functionality
would be beneficial. Because you could get an object
reference to any specific form in the collection, you could
always communicate with the precise form you need in
any situation. If that form isn’t available, the Forms
Manager can indicate this as well so that you can
proceed accordingly.
Example 2—the dialog box
Another problem that the Mediator pattern helps to
solve is the issue of communications between reusable
containers that are conditionally appearing in yet another
container. Most dialog boxes contain interface elements
that are used throughout an application. For example, a
file-selection dialog box contains a directory list box, but
the dialog box is hardly the only need for that control.
Also, dialog boxes usually have controls that turn on/off
or become enabled/disabled, based on the conditions and
state of other controls in the dialog box. For example, if
the user absolutely must choose a file, then the “OK”
button would be disabled until the user has selected a file.
Obviously, dealing with all these layers of
communication can become a problem, especially if the
same control/container appears in a variety of dialog boxstyle
interfaces. Enter the Mediator pattern as an elegant
solution. By providing a single point of interface for all
the controls in the dialog box, the problem of changing
the state of other controls becomes centralized.
The dialog box shown in Figure 2 is a simple example
of a window that contains three different containers. Each
of the containers provides a mechanism for setting a value
to on or off, while only two of them provide a mechanism
for displaying the current state of that value.
The key here is that the dialog box can have any
number of similar containers added to it without a change
to anything else. That is, none of the other controls in this
dialog box would require changes, nor would the dialog
box itself, which is serving as the Mediator component in
this case.
Each of the containers in the window has two
methods that allow it to interact with the dialog box.
These are UpdateMediator() and SetControls(), which
respectively communicate with the mediator to reflect a
change in state and receive messages from the mediator to
update their member controls. For example, the container
with the check boxes contains the following
UpdateMediator() code:
Figure 2. A simplified dialog box that allows for setting a formwide
value either on or off. While three of the containers can set
the value, only two display its current state.
8 FoxTalk December 1998
http://www.pinpub.com