Wai Wai,

Others have given you some advice on how to approach this problem. I would suggest that you ask the following question and carefully think about the answer, "Why does a button in FormB care about or need anything from a button in FormA?"

If FormB's button needs to provide a behavior that FormA's button does, then it is very possible that the button in FormA is the wrong place to have that behavior reside.

I would propose that the code in any button's click event should never be anything more than a method call to something else that actually does the behavior. A button exists for one reason and one reason only, to allow the user to click it. A button is not responsible for moving a record popinter or anything else. It is a simple communication object between the user and the application and that's all it should be.

Now, if the button in FormA is designed this way, then there is no reason on earth that we would ever need to call its click from somewhere else, we would simply call the same routine it calls. If we design that routine so it is a method of FormA and FormB needs that behavior, well that's another problem in the design. We made the behavior internal to FormA and it is not (because another form needs it to). How do we handle that? There are a nubmer of ways.

One is to make a form class and put the behavior there, then make both FormA and FormB instances of that class and inheriting the behavior.

Another is to put the behavior in a separate class defintion for an object that resides outside of both forms and have the buttons call that behavior from both forms.

Which way is best depends on what the behavior is and which object is naturally responsible for that behavior.