Khurrim

> Q1. My seniors dislike formset very stronly despite above benefits mentions by VFP if formsets are not good then why this option is carry on & not mentioning Included for backward compatibility.

You should add this quote, also from the help file, under FORMSET OBJECT:
A form set is a container object that contains a set of forms. Form sets are similar to screen sets used in previous FoxPro versions.

You might also consider that the help file is not always "updated". New things get added, and (usually) when something changes the relevant entry is updated, but otherwise things just persist. For example, if you read the help file entry on "Visual FoxPro Converter" you will see that despite the "VFP 9.0" heading, it is talking about VFP 3.0!!

You will also find this text there:

Visual conversion
Visible only when converting FoxPro 2.6 screens or projects. This option creates images of forms and all controls but copies all the code from the original FoxPro 2.6 project or screens to a noncompilable program (.prg) file. When you select this option, Visual FoxPro prompts you to create a .prg file.
To move to full Visual FoxPro functionality without eliminating pages and page frames, changing the form set WindowType Property, and manually relocating code from object to object, choose Visual Conversion.

Note the reference to the formset here! Visual Conversion creates formsets!

In short, your Seniors are correct about this one. Here is the message I posted the other day listing the disadvantages of formsets:

First, they break the most basic rule of OOP which is that an Object should be self-contained and not reliant on any external obejct for its implementation. In other words they require breaking encapsulation.

Second, they also break the second rule of OOP which is that interaction between objects should be handled through message passing, and not by tight coupling (i.e. when one object explicitly calls the Properties or Methods of another).

These two features alone explain why the only modern (object oriented) languages that support the concept are Delphi and FoxPro - both are OOP Developments of older "procedural" languages and both implemented FormSets for the same reason - Backward Compatibility with their procedural forbears!

Third, the backward compatibility issue is also what drives the Properties, Events and Methods associated with a Formset. For example there are properties on a Formset that have neither meaning nor function in an OOP environment (ReadLock, ReadCycle, ReadForeColor, ReadMouse, ReadSave, ReadTimeout, WindowList, ReadActivate(), ReadDeactivate()
ReadShow(), ReadValid() and ReadWhen()) but which are only present so that when converting a FoxPro 2.6 Screen Set, the code will not break.

Fourth the formset adds an additional, unnecessary, object to the system and introduces an additional, unnecessary, layer of indirection to Object messaging. The tight coupling of forms/toolbars within a formset can itself cause issues with VFP's garbage collection mechanism. Dangling Object References and the concomitant system crash are much easier to achieve with a formset than without. (Translation, they are not very stable!)

Fifth it requires working with multiple forms simultaneously in the designer. This is extremely dificult, and error-prone (it is too easy to change PEMs in the property sheet and then find out you had the WRONG form, or even the FORMSET object selected instead of the one you were trying to change - which object's "click method" did you just edit....?). This is because the whole VFP form management mechanism and even the designer itself, is geared toward a one-to-one relationship between Form and SCX file. In fact, whenever you edit an SCX, the entire file is deleted and re-created on save (this is why you do not need to pack an SCX, but DO need to pack a VCX). So when you change one item on one form in a formset you are deleting and re-creating ALL objects on all forms.

Finally, there is absolutely nothing that you can do in a Formset that you cannot do just as easily without one. Even sharing a common DataEnvironment (which is the most often cited 'excuse' for using formsets) is easily achieved by simply having a master form which carries the DE and then setting all other forms to use "default" datasession.

I am sure, given time, I can come up with a few more reasons NOT to use formsets, but for now I'll summarize by saying that "Formsets are a feature of VFP intended solely to support the conversion of FP 2.6W ScreenSets". Unless you are actually doing that, there is no requirement that mandates the use of a formset.

Remember, just because you CAN do/use something, does not mean that you SHOULD do/use it.


Regards
Andy Kramek
Microsoft MVP (Visual FoxPro)
Tightline Computers Inc, Akron Ohio, USA