MODIFY REPORT

SaveAs, SaveAsClass

These two very cool methods let you create a form or object, make changes, then save the changed form or object (or some control on it) for future use. They're incredibly handy when you're trying to get something just right. These two methods work only on visual objects—one more argument for doing everything in VCXs rather than in code—though we hope that limit will go away eventually, leading to true "two-way tools."

Like many of the non-event methods, you're likely to simply use the built-in versions rather than replace or supplement them with your own code.

Usage

PROCEDURE oObject.SaveAs LPARAMETERS cFileName [, oDEName ] )
SaveAs lets you take a running form or formset and, if you want, an existing data environment and save them together as a new form or formset. The original form or formset has to be based either on an existing SCX or VCX or have been instantiated directly from the Form or FormSet base class.

If the form or formset started out as an SCX, you have to RemoveObject its original data environment before you can save it with a new one. If the form or formset originated via CreateObject() or NewObject() (whether from a VCX or the base form or formset class), you can specify the data environment object without having to do that prep work.

Usage

PROCEDURE oObject.SaveAsClass LPARAMETERS cClassLib, cClassName [, cDescription ]
SaveAsClass goes a step further, which makes it a lot more useful in our book. (Yeah, this is our book and we say SaveAsClass is a lot more useful than SaveAs.) With SaveAsClass, you can take pretty much any object and save it, as is, into a class library, from which you can instantiate to your heart's content.

SaveAs lets you subclass a form or formset on the fly. SaveAsClass lets you subclass just about anything on the fly and make it a class that you can use as needed. SaveAsClass works for any of the objects that can be subclassed visually. As with SaveAs, everything in the object you want to save has to have started out as a visual object. You can't start with a code class and end up with a visual class.

Note that the parameters are all character, though Help implies that they're names without quotes. We strongly recommend that you always include the optional cDescription parameter so you can remember later why you saved this class.

The class library you specify does not have to exist. It'll be created if it doesn't. Watch out, though—this means that a typo can lead to a new VCX. We find that we tend to expect the class name to come before the class library in the parameter list and get it wrong a lot of the time.

Example

* Execute these commands from the Command Window, * substituting your form for MyForm DO FORM MyForm * Choose a new backcolor WITH _SCREEN.ActiveForm   .BackColor = GETCOLOR()   .Caption = "Testing SaveAs"   .SaveAs("MyNewForm") ENDWITH   * If we want to add a new data environment, we need  * to remove the old one _SCREEN.ActiveForm.RemoveObject("DataEnvironment") * Now create a new one oDE = CREATEOBJECT("DataEnvironment") * Change its name just so we can see the difference oDE.Name = "TestDE" * Now save a new form _SCREEN.ActiveForm.SaveAs("MyNewDEForm",oDE)   * Now save a class from this form _SCREEN.ActiveForm.SaveAsClass("Test","MyNewForm", ;     "Testing SaveAsClass") * Now you can close the original form and  * check out the various clones

See Also

ActiveForm, Create Class, Create ClassLib, CreateObject, Do Form, _Screen, Set ClassLib


View Updates

Copyright © 2002 by Tamar E. Granor, Ted Roche, Doug Hennig, and Della Martin. All Rights Reserved.



Hacker's Guide to Visual FoxPro 7. 0
Hackers Guide to Visual FoxPro 7.0
ISBN: 1930919220
EAN: 2147483647
Year: 2001
Pages: 899

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net