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?

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