[Message Deleted]

Yathish hatter

[Message Deleted]

Anthony Mushrow

Well, you could have Form1 register for Form2's OnClosed event. That way Form1 would be told when Form2 was closed.

My current favourite word is: Nipple!

-SK Genius

Game Programming articles start -here[^]-

BillW33

If you do not need Form1 to remain responsive then you should make Form2 modal ( start it with Form2.ShowDialog() ). Then when Form2 closes the code in Form1 picks up on the next line so you can re-enable the button then. Something like: Form1.btn.Enabled = false; Form2.ShowDialog(); Form1.btn.Enabled = true; If you need Form1 to remain responsive, other than for the button that opens Form2, then you should make Form2 non-modal ( Form2.Show() ), have Form1 listen for Form2's Close event and re-enable the button when Form1 responds to Form2’s Close event.

modified on Tuesday, September 9, 2008 5:23 PM

zafersavas

The answers above are all quite helpful and here is the source code to help you: In Form1:

private void myButton_Click(object sender, EventArgs e)
{
changeMyButton(false);
Form2 frm2 = new Form2(this);
frm2.Show();
}
public void changeMyButton(bool state)
{
myButton.Enabled = state;
}

In Form2:

Form1 form1Ref;
public Form2(Form1 fRef)
{
InitializeComponent();
form1Ref = fRef;
}
private void Form2_FormClosing(object sender, FormClosingEventArgs e)
{
form1Ref.changeMyButton(true);
}

Good luck zafer

DaveyM69

This is not a good way to do it - passing references of a form to the constructor of another - yuk! Why not just suscribe to the second form's FormClosing event? Something like...

    void myButton\_Click(object sender, EventArgs e)
    {
        myButton.Enabled = false;
        Form2 frm2 = new Form2();
        frm2.FormClosing += new FormClosingEventHandler(frm2\_FormClosing);
        frm2.Show();
    }

    void frm2\_FormClosing(object sender, FormClosingEventArgs e)
    {
        myButton.Enabled = true;
    }

Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Expect everything to be hard and then enjoy the things that come easy. (code-frog)

zafersavas

Sorry I disagree, what do you mean by "not good"? Are you aware that in form1 code you are writing code related with form2. What if you have form3, form4 etc. Than your form1 gets larger and larger. Passing the reference of the main form to other forms is a practical way of form communication.

DaveyM69

Form2 has no purpose to know about form1 at all. It does nothing with it at all so the reference it pointless. Form1 however neeeds to know when form2 is closing so it should listen for that event. That's what events and delegates are designed for. If any object needs to tell any other objects about anything at all it should raise an event so any interested (subscribed) objects can react.

zafersavas wrote:

What if you have form3, form4 etc.

This applies the other way too - what if you have multiple objects that need to know that form2 is closing? You'd need to pass every object in the constructor. How can you predetermine how many there will be or what types? It makes the constructor(s) virtually unmaintainable. By using events/delegates there is no limit to the number or type of objects that can have methods invoked from the object raising the event. That's what OOP is all about! :-D

Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Expect everything to be hard and then enjoy the things that come easy. (code-frog)

zafersavas

Well, this topic seems going deeper :)

DaveyM69 wrote:

what if you have multiple objects that need to know that form2 is closing? You'd need to pass every object in the constructor. How can you predetermine how many there will be or what types?

absolutely no, no and no, have a look at this: Form1 : is the main form, Form2 and Form3 are declared here. Form2(Form1 frmRef); Form3(Form1 frmRef); 2 knows 1, 1 knows 3 so 2 can know 3 through 1. Just pass Form1 as a constructor parameter and dont think the rest. As every form is aware of Form1 and Form1 is where other forms are declared, this means "everybody knows everybody". Form1 is something like a common node for all others. So as you see you dont have to pass other forms to the constructor. Anyway, its a way up to you. No problem if it is efficient and causing any trouble. Kind regards zafer

DaveyM69

zafersavas wrote:

Well, this topic seems going deeper

:-D Yeah, don't want to get into this too deep - this board probably isn't the right place, and don't want to hijack the thread! You say tomato, I say... etc etc.

Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Expect everything to be hard and then enjoy the things that come easy. (code-frog)

nelsonpaixao

my advice is forget it, begin from start!!! :laugh: use one of those methods: - parent form & child forms (here you can open and close as many forms you like inside parent form) - main form & usercontrols (userforms load/triggered in main form like pages) is there a good reason for doing that? :doh: try those methods (you have many articles in codeproject) and will talk later Good luck ;)

nelsonpaixao@yahoo.com.br trying to help & get help

Mycroft Holmes

Adding the event - thats cool. Presumably you could also use the same method for any child form simply by adding the formclosing event. If you needed custom processing for a particular form use a switch on the sender name. Oh joy, new toys to play with.

Never underestimate the power of human stupidity RAH

DaveyM69

Mycroft Holmes wrote:

Presumably you could also use the same method for any child form

You can do anything you like with it. Eg.You can respond to events from objects that are part of the child form too by either making them public (not recommended) or better still, in the event handler on the child, fire a new custom event that the other form can listen for. the possibilities are endless... :-D

Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Expect everything to be hard and then enjoy the things that come easy. (code-frog)