>Thanks to all...I am using private data sessions...
>
>> Normally, application has more extended mechanism usually called Form Manager.
>
>That's what I remember reading about SOMEwhere...can anyone point me in a direction to find out more (information/examples about Form Managers)?
>
>TIA

Jill, there are lots of examples out there that show how to build a form manager (Like John said, you can download a demo or freeware framework to see how)- but IMHO, most of them aren't implemented right.

A form manager's purpose is to serve as a central place for forms and other application object to talk to forms. Your application object or startup program might create it at app startup, and make it accessible either through a property of a global application object, or through its own global variable. The idea is to have one object that keeps track of all running forms. So if Form A needs to tell Form B to refresh itself, it doesn't guess at FormB's location or referencing variable, but rather accesses it through the forms manager or just tells the forms manager to tell all forms to refresh themselves.

For the forms manager to keep track of all the running forms, the forms have to somehow be registered with the manager. Most of the frameworks out there require that you do this by calling a oForms.DoForm method. This method then adds the form to its internal collection, therefor "registering" the form. This is a design I strongly disagree with. Using a forms manager that requires this makes retrofitting your application with a forms manager a very laborious task. Every place in your code where you issue a DO FORM, you have to replace it with the new syntax. Now that all of your code uses the new form calling syntax, you also have to check for the existence of and create if necessary, the forms manager if you ever want to test your forms from the command window.

Passing parameters to the new form takes on a whole new dimension, as you are forced to pass them to the forms manager, who then passes them on to the form. This entails building a single, delimited parameter, writing a BUNCH of forms manager code to sort the parameters out and pass them on, or constructing a parameter object to store parameters each and every time you call a form. Not to mention the difficulty involved in trying to get a return value from a modal form. Ick.

My forms manager is much simpler. I simply put code in the load event of my base class form that registers the form by passing itself as a parameter:

IF TYPE("oForms.Name") = "C" && Make sure forms manager exists
oForms.Register(THIS)
ENDIF

This way, my form calling syntax doesn't change a bit, and I am not burdened with changing my whole form calling style just to make use of a forms manager.

Now the DoForm method can have advantages- if you use vcx based forms (I never do) the DoForm method can make calling syntax easier by wrapping the CREATEOBJECT code for you. (Not as much of an issue with the advent of NEWOBJECT().

Have a look at the examples out there for an idea of what all a forms manager can do for you, and if you have questions, please post them.

HTH