Should I create class instances or modify actual forms 1

[TomLeMes]

Sorry if this question betrays the gaps in my understanding of classes, but here goes. I've created a class of form which contains a grid, a drop-down which can be used to filter the grid and several buttons to select records, create a new record or close the form.

Now I want to create specific versions of this form with different data selections, numbers of columns and so on (for users, customers, banks etc.) Is it better to:

A) Subclass my generic form and so create classes with the specific details set. The main form in my project can then just call instances of the subclasses required.

or

B) Add multiple instances of the generic form to my project and then make the required modifications to each instance.

I'm just wondering if there are any principles that make once approach more logical/efficient than the other. Is it better to load up my class library or the forms section of my project? Or am I missing the point here?

Tom

 

[Mike Lewis]

Tom,

Sorry if this question betrays the gaps in my understanding of classes,

On the contrary. The fact that you have thought it through this far suggests that you do understand the issues.

Personally, I wouldn't do either option. I would create a container class, containing the grid, buttons, etc. Then create a new form for each instance, based on a suitable form class. Then drop an instance of the container on each of those forms.

That way, you can combine the grid functionality with whatever other functions you want for the form -- assuming that's something you would want to do in your app.

That's just my opinion. Let's see what other people suggest.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[MarciaAkins]

Now I want to create specific versions of this form with different data selections, numbers of columns and so on (for users, customers, banks etc.) Is it better to:

Personally, I would have a vanilla generic grid class with base functionality ( clicking on the header allows sorting by that field, dblclick calls up an editing form to edit that record in the grid, and so on ) and vanilla generic form calles for data entry forms, pop-up child forms and so on.

Then, I would configure my grid in the instance of the form based on the appropriate form class.

Generic functionality in the class libraries - application specific behavior in the instance.



Marcia G. Akins

http://www.TightlineComputers.com

 

[TomLeMes]

Thanks Mike and Marcia for your helpful posts. In a similar vein (construction options for applications) I'd be interested in opinions on the following:

I'm currently in the early stages of making a medium sized in-house application (concerned with loans, financing and credit limits) - bigger than anthying I've done before. It will contain quite a few different sections, each comprised of multiple forms, reports, functions, etc.

When making something like this, is there some way that people tend to split things out within VFP? What I'm thinking is that with a project of this size there are going to be loads and loads of forms, reports etc. within the one project - does this pose any potential problems?

Similarly, are there any guidelines that I should follow for splitting out my class library? In the past I've just had the one class library with all my controls contained within. I gather that people don't do this but I'm not really sure why or what the issues are. Thanks,

Tom

 

[Mike Lewis]

Tom,

When you say "loads and loads", roughly how many are you talking about? A few dozen? Hundreds? Many hundreds?

I've worked on several projects where the number of forms has been between 50 and 100, often with a similar number of reports, but usually fewer menus. Those figures are not outlandish.

In general, your project should be able to cope with those numbers without too much problem. Just be sure to give each component a sensible name, and also -- strongly recommended -- use the Description field in the Project Manager to enter a meaningful comment about each item.

However, my present project has around 60 forms, but I have recently been required to merge it into a larger project that other developers are working on. We will have approaching 500 forms in all.

We are finding it difficult to manage that number of forms (especially as there is some duplication in form names), and have decided to split the forms directory into sub-directories, one for each main module. We have adopted a naming convention, whereby the form name begins with a two-letter module code and an underscore (same convention for reports).

Each module has its own project, which is working OK. The problem occurs when we need to build the entire application. We don't want to swamp an individual project file with all 500 forms, so we have set up a separate project just for the purposes of doing a build. I'm not sure if that's a good approach, but it's the best we have come up with so far.

As far as class libraries are concerned, I tend to stick to the following:
- A root library, containing first-level subclasses for each of the built-in classes.
- A controls libraray, containing all my generic controls, gadgets and gizmos.
- A forms library.
- Additional libs for certain classes that don't really belong to the project, such as third-party stuff, or my "published" classes (which I keep separate for distribution purposes).

I hope these ideas are useful. I'd be interested in reading what others think.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[TomLeMes]

Thanks Mike,

I suppose "loads and loads" is a bit of a subjective term isn't it?! In this case it translates to around 50-60 forms so I can rest easy. And thanks for the pointer about the description field - part of my concern is keeping things in order so I don't end up with a chaotic mess that is a nightmare for me (or others in future) to maintain.

Tom