Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
10 Things to Avoid in VFP Development
Message
De
31/12/1999 13:11:48
 
 
À
31/12/1999 11:50:35
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00310318
Message ID:
00310965
Vues:
35
Hi Kevin ---

>I agree with your mantra on PUBLICs.

Not my mantra. Jim Booths. I just happen to agree with it 95%.

>I TOTALLY agree with FormSets. I feel almost as strongly about FORMSETS as I do about the ability to add properties at runtime in VFP 6...neither should ever have been introduced, because they give newbies the chance to go down a dark road...

Ack! Now, putting Formsets and AddProperty in the same boat....I make use of AddProperty in some code and I love it. For example, I might want to store information about open tables for a form at runtime. How else do I efficiently do that besides add an array property with AddProperty?

>You're right on the REFRESH(). Also, avoid too much code in the INIT().

Less of a problem. Init fires once. It's a good place to put code because the form is not displayed yet and if there is a slight pause in Init, no big whoop. OTOH, Refresh fires fairly frequently and the screen is up.

>I disagree with SET FILTER. While it should be used sparingly, it can be handy (if it's handled correctly).

In rare, rare cases. The only thing that comes to mind is when allowing edits on a parent-child-grandchild setup. You table buffer the grandchild and use set filter to limit the records available because you can't requery the grandchild if the child pointer moves without busting up uncommitted changes but you can reset a FILTER.

>On the SETs, this should be handled by a form class. I did it once three years ago and haven't had to worry about it since.

OK....this begs the question: Where in your Form class?
------------------------------------------------
John Koziol, ex-MVP, ex-MS, ex-FoxTeam. Just call me "X"
"When the going gets weird, the weird turn pro" - Hunter Thompson (Gonzo) RIP 2/19/05
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform