Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Why not formsets?
Message
 
À
08/12/1998 20:05:45
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Divers
Thread ID:
00165334
Message ID:
00165423
Vues:
18
>>Mark,
>>
>>In addition to what David has said;
>>
>>1) If a formset is to contain a form that other fomrsets also need, you can't use the same form. You nedd to duplicate the fomr in all formsets that need it instead of just calling the form you need.
>>
>>2) In most formsets I have seen the first thing that happens is to hide a bunch of forms. By using separate forms you don't hide anything because you don't create the form until it is needed.
>>
>>3) Formsets must create all contained forms even if the user will never visit some of them. This takes time and I prefer to have the user wait only for the forms that they are actually going to use.
>
>Here's a curve on this - I've been writing all my forms as class definitions in .vcx files lately. It seems to me that this allows for moreflexibility in choosing their parent class and their functionality. The only thing I lose are the built-in DataEnvironment (which I write in code) and the TO clause, which I use an exit property for. Am I missing anything?


Not that I can see except that you have sort of stumbled onto the Codebook basic scheme. The thing that Codebook does to plug your DE is to build DE classes through the adataenv.prg and then call those classes to the form through the CDELoader and CSessionEnvironment Objects that become part of the class which includes the form. It only took me a year for the light bulb of all of this to go on but it does help all of this to dovetail into an organized conglomeration of reusable code.
CySolutions, Medical Information Technology
You're only as good as your last
success, so . . .If it works. . .don't fix it!
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform