Hi Terry.

So I am always on the prowel for code gurus like you to help me with the geeky stuff.

I do a fair bit of analysis and design work as well < s >. And there is a lot of the "geeky" stuff that I don't know either. The important thing is knowing where to get the answers when one needs them.

In these cases, if we review VFP documentation, the form name has to be a public variable.

I don't think so < s >. If you instantiate a form manager in your main program with private scope, he is available to the rest of the app. Then the form manager can handle any of the dependencies between the forms in his collection.

ARe you able to force a n action on form B from form A without form B being publicly referneced.

See above < s >.

How do you solve the problem? Two (or more forms) where a change on one (like a navigator object) affects the output and processes (even may call a method of an alien form:). Are you able to reference "other" MDI forms without a public handle.

Off the top of my head, suppose something happens in formB that needs to be broadcast to the other forms in the environment so that any other form who is interested in what happened can take action. FormB can call on the services of the form manager like so:

oFormManager.HandleEvent( Thisform ).

The form manager can then handle broadcasting that some event occurred to the other forms in its forms collection. This way the forms are not so tightly coupled as they are when you have all the forms in a free-for-all referencing each other's properties and methods willy nilly < s >.

Just a thought...