>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...

Adding properties is not all bad, it cna be a very powerful design approach to reusable objects. However, it should definitely be added to a list of potentially abused VFP capabilities.

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

As a general rule there should be very little code in all event-methods. Event-methods are not there to provide behavior, they are there to respond to events. Event-methods should always call another method with the behavioral code.

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

Again, I say as a general statement that SET FILTER is more ogften misuesed than it is used correctly.

>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.

Actually, it should be handled by a setEnvironment class that the form class creates. That makes it avaialable to other things besides forms, like reports.

>On the primary keys, this rule goes back to Grace Hopper (haven't used THAT name in awhile!)

Get your point, but Grace was teh COBOL lady, it was CODD that was the RDBMS guy.