I CLASSES AND SUBCLASSES are behaviours added to your programe thru codes created as foxpro command code or Visual creations.
Imagine the record nvigators .. like the VCR buttons for skipping the records in a table. You can create a navigation class... with first/last/previous/next record buttons with codes GO TOP, GO BOTTOM, SKIP -1, SKIP codes in these button click events. Then these collection of buttons, can be classed as NavigationClass and when added to your forms, they will do the functions for the default alias of the form. YOu can use it many forms again and again. So the navigationbutton class can help you easy your coding everytime.
Now said the above, in a particular form, you want to change the behavior of a button, you can still do so.
You can subclass them to inherit all the codes, and do some extra code or avoid the parent class codes and use the sub class in your foms.
This opens up a whole new convenient way of programmes.
Remember the Fox 2.6 days.. in fact I have done many of these class behaviours using proper codes which can be called up as FUNCTIONS and added with SET PROCEDURE TO codes. When called, they will do the intended processing with values passed on as parameters. The same can now be done with class codes with lot more ease in change its behavious based on circumstances.
This is a subject you have to read in some text books or else we can keep writing the whole day on this.
Hope this helps you ramani :-9
(Subramanian.G),FoxAcc, ramani_g@yahoo.com
Object oriented design sin't that difficult but can be troublesome to grasp. Most people I have worked with or talked to, told me that it usually takes about 2 or 3 months to get the hang of it (which also was my own experience), when coming from a procedural programming environment.
Believe me, it is worth the effort. All time spend in learning the concept of OOP is paid back in the future and saves you a lot of time coding.
But then again, designing software should be 90% preparing and thinking it over and 10% coding.
Unless you'd like to stick to 'code and fix development practices' ;-)
One thing you should do if you're beyond the stage of just playing to learn and want to create something you'll use in the future, is to subclass all of the VFP base classes into your own class library and then set it as the default class library which you use when creating your forms. (And subclass the base form class too). The reason you want to do this is that you may someday want to change something in all the projects you've created, a new logo, a special error handler, information concerning copyrights, etc. The VFP base classes can't be changed, but a subclass can be. Therefore if you have 10 projects using the FKTextBox (your subclass of the textbox baseclass) you can change them all by making the change directly to the FLTextBox class. But if each of the 10 projects uses the VFP base textbox class, you have to go in and make whatever change you want to every example of the textbox in every project. This is not a good use of your time.
Note, you'd still have to recompile each project to have the change show up in the projects, but if you're running them in development mode on your computer the change will be automatic as the changed classes will be used directly by VFP when it creates the objects you see.
Now in addition to such universal changes, you'll probably also want to further subclass your own classes for major projects, say for a specific customer so that if they change their name from Gadgets, Inc. to Megagadgetco you can change this on the forms where it's displayed without also changing the names of other companies.
Finally you'll soon find yourself wanting to create specialized classes which have capabilities beyond that of the VFP base classes, or which are combinations of several other classes. Depending upon whether these are just to be used in one special project, or by numerous projects you'll want to place these in your main class library or at some lower level.
One thing you need to remember is that if you copy your class library you've essentially cloned it and thereafter they're seperate entities. Therefore you always want to point each new project to your 'main' class library (or to the specific subclassed library you've created for that project / customer.) [note: I've messed this up myself and consequently have various versions of my libded floating around. I've started cleaning up the mess, but never seem to have time to finish it.] Dave Dardinger
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.