The L.A Fox Developer Newsletter

September 1999

Automating FOXPrO (Con’t from page 4)

executable is run with the following VFP main.prg.

!start 1w monarch.exe k:\a2mjm1.001

g:\a2mjm1 .mod g:\apps\adhoc\a2mjm1 .dbf

!start 1w monarch.exe k:\a2mjm2.001

g:\a2mjm2.mod g:\apps\adhoc\a2mjm2.dbf

Istart 1w monarch.exe k:\a2mjm3.001

g:\a2mjm3.mod g:\apps\adhoc\a2mjm3.dbf

!start /w monarch.exe k:\a2mjm4.001

g:\a2mjm4.mod g:\apps\adhoc\a2mm4.dbf

!start 1w monarch.exe k:\a2mjm5.001

g:\a2mjm5.mod g:\apps\adhoc\a2mjm5.dbf

!start 1w monarch.exe k:\a2mjm6.001

g:\a2mjm6.mod g:\apps\adhoc\a2mjm6.dbf

cd g:\apps\adhoc\

!pkzip -u -sPW denhlth *.dbf

wait timeout 120 && 2 minutes

erase k:\a?mjm?.*

do form mailforl

read events

clear events

return

Note, because Win 95 is a multitasking operating system, the

START/w DOS command delays the start of the second MON-

ARCH call until the first is complete.

Create a form called mailforl .scx. In form mailforl, INSERT two

OLE controls. Select the OLE toolbutton and then select

INSERT CONTROL and select MICROSOFT MAPI

MESSAGES CONTROL and MICROSOFT MAPI SESSION

CONTROL.

n the INIT method of form mailforl type the following code:

thisform.osession.signon()

IF THISFORM.osession.sessionidO

MESSAGEBOX(”failed to log onto email server”)

RETURN

ENDIF

WITH THISFORM.omessage

.sessionid=THISFORM.osession.sessionid

.compose() && allows you to set the following properties

.recipaddress = “PlUS” && distribution list

.resolvename()

.msgsubject = “Today’s ADHOC databases: “+dtoc(dateo)

.msgnotetext = ‘The attached document contains SMS databases’

.attachmentname=’denhlth.zi p’

.attachentpathname-'g:\apps\adhoc\denhlth.zip

.SEND(.F.)

ENDW1TH

thisform.osession.signoff()

9* msgindex property - index of currently selected msg,

*!*set to -1 to compose new msg

1* msgsubject property - subject line of email (max 64 chars)

1* recipAddress property - email address of recipient

“1” compose() - call to begin composing a new message

!~ attachmentname property- filename

*!* attachmentpathname property -pathname

(Con’t, page 9)

Inter-Object Communications

in Visual FoxPro

Part I

By Steve Sawyer

[Ed. Note: Part I of a two part series to be concluded next

month.]

Messaging is a central component of object-oriented program-

ming. It is the mechanism by which one object in an application

communicates with another. Because many of the “things” you

deal with in Visual FoxPro (forms, form controls, toolbars, the

screen etc.) are objects, being able to integrate their functioning

is important!

Both in concept and in execution, inter-object communications

is a very simple process: an object message is nothing more

than a call to a function which is contained in an object. In OOP

terminology, a function contained within an object is called a

method.

At its simplest, an object message is simply a line of code in a

program, or in the method code of an object, which calls a

function in an object using appropriate object syntax:

<ObjectReference>.cMethod>

For example, if we have two objects, oToolBar and

oDataEntryForm, oToolBar can send a message to

oDataEntryForm by executing the following line of code:

oDataEntryForm.GoNext()

The result is that the code in the GoNext() method of the

oDataEntryForm object is executed.

One can think of objects as procedure files containing user-

defined functions. “Messaging” is simply the process of making

calls to those functions. However, a significant difference is that

with a procedure file, we can simply SET PROCEDURE TO

<filename>, or SET PROCEDURE TO <filename> ADDITIVE

and all of the UDFs in all of the open procedure files are avail-

able to us.

In the case of object messaging, however, we must be explicit

about which object’s method is to be executed. In fact, this is

one of the characteristic strengths of object-oriented program-

ming, which is called polymorphism. This is the ability to have

multiple objects, all (for instance) with a Print() method, and

each Print() method capable of performing different, appropriate

actions depending on the object to which it belongs.

While this is very simple, actually implementing user-defined

objects in a working application introduces some messaging

problems that are not immediately obvious. Developing your own

(Con’t, page 5)

Page 5