forms over classes.. classes over forms...

[thatguy]

hey all!

so i'm almost done with my first big project and suddenly i'm wondering about a choice i made when i started.. for some reason, i decided to make every form in the project a class (so in the project manager, there are no forms listed in Docs, because they're all in a forms library in Classes).

at this point i'm wondering why i did that. i tihnk i recall some article about form classes being better somehow, but i can't remember why. can anyone tell me which way is preferable? pros and cons of either method?

thanks.
-- michael~

 

[DEDMOD]

Well, one big advantage of classes is that they're reusable in other projects. But if you make *every* form a class, you'll probably not get too much benefit. Of course, since this is a first project, you'll probably want a lot of forms similar to the ones you created in future projects and it'll be convenient to have them when you want them. So you might come out ok.

Another advantage of having classes instead of forms is that you can make needed changes to forms in many projects all at once. Things like changing a logo displayed in them, or making an improvement in how a particular button handles user input, or in adding error checking which you'd left out because it seemed too complicated at first.

I assume you first created your own version of the base form class and then created the other classes from that? This is necessary so that you can make changes to all forms at once. OTOH, it's often a good idea to create a new base form for each project so that you can make changes to all the forms in the project at a later time without affecting the forms in other projects.

Since the above ideas; being able to change all forms and being able to reuse old forms somewhat contradict themselves, you need to decide how you want to do things in the future and create your own standards.

One disadvantage of using classes instead of forms is that at each layer the code in the previous layer is hidden. This means that if you want to figure what's going on you may have to work your way up the chain of classes and subclasses to find the code you're interested in. Not to mention having to remember to use DODEFAULTs if you add code to a method which has code you need in it in a higher level.

Another disadvantage is that if you're creating .exes or .apps they will include the entire library in which a form you want is located. So if you pick form class 1 from Alib with 20 classes and class 2 from Blib with 15 classes, you'll end up with all 35 classes in your app even though you're only using 2 of them.

Hope this rather rambling message is useful.

Dave Dardinger

 

[weedz]

Dave,

As always, I totally agree using OOP and for not seeing code that has been defined in super classes, this can be solved using the magnificent tool of the superclass utility by Ken Levy. Just follow this link:

http://msdn.microsoft.com/vfoxpro/downloads/download.asp?ID=015

having al those classes in your exe, when you have made good use of OOP, sublassing, this should not be a problem.

HTH,
Weedz (Wietze Veld)
My private project:

http://www.crowncap.demon.nl\info\crwnbase

And especially for VFP rookies:

http://fox.wikis.com/wc.dll?Wiki~VFPRookieMistakes~VFP

 

[foxdev]

As Dave explained, there's nothing inherently wrong with making each form a class.

But I had experience with one client where nearly every form was a class (IOW, each was instantiated only once), and it created a big problem: since each of these "form classes" was stored in the same .VCX, it made reliable code sharing/multiple checkouts by several developers at once pretty much impossible. Of course, if you're working alone, its not an issue. Robert Bradley

http://www.agrainofhope.org

http://www.lowcostprints.com

http://www.foxdev.com