The LA Fox Developer Newsletter

September 1995

Visual FoxPro

Where Does Code Go Now?

by Michael Meer

If you’ve worked with Visual Foxpro recently, you

might have noticed that our familiar setup, cleanup

and show gets are gone. The when and valid are

still around as methods, for now. But where do you

put the code that used to go in the setup, cleanup

and show gets?

Setup code is now broken into two places: the Form

LOAD and the Form lNlT. In Foxpro 2.x, if you

wanted to perform some commands prior to the

actual read objects creation, you’d put in the #SEC-

TIONI command at the top of the setup command.

Any code that went here now should be shifted to

the Form LOAD. You’ll notice that only the form has

a load event; textboxes, spinners, editboxes, etc

don’t. Any code in the Form LOAD can not refer-

ence objects on the form... they haven’t been

instanced yet! How would you perform commands in

Foxpro 2.x after the read objects have been cre-

ated? That’s right, you’d put the command #SEC-

TION2 in the setup command prior to those ccm-

mands. They would then be executed after the

window had been created and the gets had been

initialized. In Visual Foxpro, you would put those

commands in the Form INIT. The Form INIT is “fired”

after the Form LOAD and all object IN IT’s. Thus, all

objects now exist and can be referenced. Below is

some examples of code that would go into each of

these sections.

So now we know where to put setup code, but what

about cleanup code? What type of code is put in the

cleanup snippet? End of screen code and auxiliary

procedures. First, end of screen code can now be

put in the DESTROY method. This method is ‘fired’

after you do a THISFORM.release() or the

QueryUnload method. (Note: The QueryUnload

method is ‘fired’ after the user double clicks on the

top left corner or chooses close.) Now, what about

the procedures we all put in the cleanup code? Each

procedure now becomes a custom user defined

method. Then, the code is available whenever the

form is alive. For example, you want a procedure that

puts a wait window on the screen and says “hi”.

Here is the code and how you would call it:

Remember, Visual Foxpro doesn’t create generated

code like Foxpro 2.6. Each object is a record in the

form or class table and thus any procedures or

variables defined in any methods WILL lose focus

once the particular method code has executed.

Finally, what about when you want to do a show

gets? How do you do the same call in Visual Foxpro?

You would issue a THISFORM.refreshO. By default,

the refresh method of the form/class will call all of the

other objects’ refresh methods. Any special code for

a particular object should be put in the object’s own

refresh method, otherwise, any generic code to

executed wheti the fort,, refreshes should be placed

in the form refresh method.

[Michael Meer is Vice-President of Microcomputer

Engineering Services, LLC, a company specializing

in custom software development and mission-critical

applications written in FoxPro. He is also a certified

Visual FoxPro trainer for MicroEndeavors. He can be

reached on CompuServe at 72426,3467.)

This just in

Looking for a new place to hang out on

CompuServe? Try “GO VFP” to access

the brand new Visual FoxPro Forum, or

try “GO PINTER” to access Les’ new

forum.

Page 4