The LA Fox Developer

The LA Fox Developer Newsletter

Where Does Code Go Now?

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 created? 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.)

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.