>Thank you Ed.
>I clearly understand your explanation. The concept of using the form manager is very convincing. However, with my limited knowledge, how to create the form manager? Do you have any article or knowledge base for me to read? Any samples?
>

The TasTrade sample contains an example of a Forms Manager class. I use a Framework derived from Visual MaxFrame Pro (an older version); you can still download Visual Maxframe and get a simple framework that contains a reasonable example of a Forms manager class. John Koziol's DESI contains a simple Form manager as I recall, and Jim Booth/Steve Sawyer discuss it in an outstanding book "Effective Techniques..." published by Hentzenwerke, www.hentzenwerke.com which covers that and much more quite well. Another Hentzenwerke title, "1001 Things You Wanted to Know About Visual FoxPro" by Marcia Akins, Andy Kramek and Rick Schummer also discusses Form managers, and is another outstanding book, which has already started showing signs of wear around here. All the major frameworks that I'm aware of, with the possible exception of frameworks that do not manage a UI, have a Forms manager class of some sort.

>>First, you need an object reference to the Form you want to access; obviously, the thisform is not going to work. Most frameworks implement a Form manager of some sort that will permit you to examine the instanced forms presently controlled by the app; the Form manager would pass you back an object reference to the Form you want to access. Once you have an object reference to another Form (for ease of reference, I'll call it oFormObj), it's easy enough to locate a Control in the Form's Controls collection, and issue a oFormObj.Controls(nControlIndex).SetFocus(), or issue a call to the form object's oFormObj.Show() method.
>>
>>You can invoke a method or access a property of another Form without making it active; ie OFormObj.Name returns the name of the Form oFormObj; a statement like
>>
>>nMyReturnVar = oFormObj.CustomMethod(parm1, parm2)
>>
>>invokes the method with the parameters passed, returning a result, without necessarily making oFormObj the active Form. Typically, if you're doing this a great deal, it's a strong indication of a flawed OO analysis; since the two forms are tightly coupled, and accidents, such as failing to release the temporary object reference to the other form may result in dangling object references, which can cause all sorts of problems. My general approach is to not return an object ref from my Form Manager, but to identify the Form to be dispatched, and have my Form manager actually be the only object that dispatches Form instances - it ensures that all my Forms are managed in a single place, and the Form manager object, a part of my application framework, is responsible for controlling the lifespan of my Forms and avoiding the dangling reference issues.