How get a reference to another form?

[Bill Todd]

Form B needs to call a public method of Form A. How can form B get a
reference to the instance of Form A using its name or any other
method? Is there a collection of form instances that can be searched?
--
Bill

[William Ryan eMVP]

You'll need to declare and instantiate a new instance of A and reference it
from there
//Within formB
formA f = new formA();
f.SomeMethod();
"Bill Todd" <[e-mail]> wrote in message
news:le********************************@4ax.com...

Form B needs to call a public method of Form A. How can form B get a
reference to the instance of Form A using its name or any other
method? Is there a collection of form instances that can be searched?
--
Bill

[Bill Todd]

Creating a new Instance will not work. I need access to the existing
instance of Form A.

I assume from your answer that the .NET framework does not maintain a
collection of form instances.

I am accustomed to an environment where referring to one form instance
form another is easy and I am struggling to understand how forms are
supposed to communicate with each other in the .NET environment.

Right now the only method I can see to do this is to have the
application's main form be responsible for creating every other
modeless form in the application. When the main form creates a new
form instance it does so by calling a static method that takes a
reference to the main form as a parameter and returns a reference to
the new form. That way all forms have a reference to the main form and
the main form has a reference to all other forms.

Is there a better way to handle this?

Just one example is the case of a database applicaiton. You cannot
write a database application where every form has its own connection
to the database. If forms are going to share a connection object they
have to have a reference to the form that contains the connection
object.

Thanks for any insight into this.
--
Bill

[DalePres]

If one form creates the other form, pass a reference to the first form to
the constructor of the second form... i.e. formA is the first form and it
creates formB with:

FormB formB = new FormB(this);

and create a constructor for FormB as:

Public FormB(FormA formA)
{
}

HTH,

Dale

"Bill Todd" <[e-mail]> wrote in message
news:js********************************@4ax.com...

Creating a new Instance will not work. I need access to the existing
instance of Form A.

I assume from your answer that the .NET framework does not maintain a
collection of form instances.

I am accustomed to an environment where referring to one form instance
form another is easy and I am struggling to understand how forms are
supposed to communicate with each other in the .NET environment.

Right now the only method I can see to do this is to have the
application's main form be responsible for creating every other
modeless form in the application. When the main form creates a new
form instance it does so by calling a static method that takes a
reference to the main form as a parameter and returns a reference to
the new form. That way all forms have a reference to the main form and
the main form has a reference to all other forms.

Is there a better way to handle this?

Just one example is the case of a database applicaiton. You cannot
write a database application where every form has its own connection
to the database. If forms are going to share a connection object they
have to have a reference to the form that contains the connection
object.

Thanks for any insight into this.
--
Bill

[Bill Todd]

How about the case where FormA creates FormB then FormB creates FormC
and FormC needs to call a method of the existing instance of FormA?

Bill

On Mon, 3 May 2004 21:31:11 -0500, "DalePres" <no****@nomail.com>
wrote:

If one form creates the other form, pass a reference to the first form to
the constructor of the second form... i.e. formA is the first form and it
creates formB with:

FormB formB = new FormB(this);

and create a constructor for FormB as:

Public FormB(FormA formA)
{
}

HTH,

Dale

"Bill Todd" <[e-mail]> wrote in message
news:js********************************@4ax.com.. .

Creating a new Instance will not work. I need access to the existing
instance of Form A.

I assume from your answer that the .NET framework does not maintain a
collection of form instances.

I am accustomed to an environment where referring to one form instance
form another is easy and I am struggling to understand how forms are
supposed to communicate with each other in the .NET environment.

Right now the only method I can see to do this is to have the
application's main form be responsible for creating every other
modeless form in the application. When the main form creates a new
form instance it does so by calling a static method that takes a
reference to the main form as a parameter and returns a reference to
the new form. That way all forms have a reference to the main form and
the main form has a reference to all other forms.

Is there a better way to handle this?

Just one example is the case of a database applicaiton. You cannot
write a database application where every form has its own connection
to the database. If forms are going to share a connection object they
have to have a reference to the form that contains the connection
object.

Thanks for any insight into this.
--
Bill

--
Bill

[Jon Skeet [C# MVP]]

Bill Todd <[e-mail]> wrote:

How about the case where FormA creates FormB then FormB creates FormC
and FormC needs to call a method of the existing instance of FormA?

Then when FormB creates FormC, it should pass the FormA reference which
was passed to it to FormC as well - or make it available as a property.

Forms are just objects, like any other. Think about how you'd solve the
problem if you weren't dealing with forms, and apply it to forms.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jax]

Surely form C should accept form B in the constructor, then as form B already has form A you have all three
I personally prefer to use delegates to do this, so as to keep my methods private, it's a cleaner method but is limited as you need a delegate for each method (so it's best if you just have one refresh method, or your just hiding the form and showing it, in which case you just send Show to the next construcotr in the form of a delegate)

jax

[Jon Skeet [C# MVP]]

Jax <an*******@discussions.microsoft.com> wrote:

Surely form C should accept form B in the constructor,
then as form B already has form A you have all three.
Well, it depends on the situation. Sometimes form C isn't necessarily
logically linked to form B, but *is* logically linked to form A - in
which case there's no need for form C to know anything about form B at
all.
I personally prefer to use delegates to do this, so as to keep my
methods private, it's a cleaner method but is limited as you need a
delegate for each method (so it's best if you just have one refresh
method, or your just hiding the form and showing it, in which case
you just send Show to the next construcotr in the form of a
delegate).

Yes, it certainly depends on what you're actually doing with the other
forms.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jax]

True, I was just considering it in progressional terms, if there are to be many forms it could be a clearer method otherwise it may end up being very confusing knowing which form references which
But still, we're just arguing semantics here, I apologise

ja

[Bill Todd]

Thanks. I think I understand what you are saying, although I have no
idea how to do it. I need to do more reading about delegates.

However, using a delegate seems like a lot of extra work for no
benefit. What is the benefit of keeping a method private when you want
to be able to call that method from other object instances?

Sorry if I am being dense.
--
Bill

[Bill Todd]

Thanks. That answers my question.
--
Bill

[Jax]

Well for example if your programming in teams and you dont other people to accidently use your methods thats where private can come in handy, it's also just a general object orientated convention to attempt to keep most of your methods private

Creating a delegate is very simple and it makes things simpler in the long run because you may modify FormA in some way it might mean you have to make changes to FormB which accepts A (it's happened to me before!). So it ulitmately keeps the two seperate which is sometimes desirable

Say if I wanted to do my usual hide delegate so one form can hide and the FormB thats spawned carries a delegate to the show method of FormA

first declare the delegate somewhere in the namespace (or elsewhere if you like

public delegate void ShowDelegate()

then in formA

FormB fb = new FormB(new ShowDelegate(this.Show))
fb.Show()
this.Hide()

Then in Form

public class FormB : For

private ShowDelegate showDel

public class FormB(ShowDelegate sDel

showDel = sDel
this.Closing += new System.ComponentModel.CancelEventHandler(FormB_Clo sing)

// then you want it to fire when formB closes so
private void FormB_Closing(object sender, System.ComponentModel.CancelEventArgs e

showDel();

Now when FormB closes, FormA will magically re-appear
If anything it's a good idea to learn to use delegates just because they're very useful things

I Hope that was vaguely interesting

jax

[Bill Todd]

Thanks. Very helpful.
--
Bill