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 MONARCH 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 programming. 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 available 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 programming, 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