Form-to-Form

[Thom Little]

I am using C # .NET Framework 3.5.

I have a calling form that invokes dialog box (called form). I want a
button in the called form to change the value of a property in a control in
the calling form.

Clearly I could set a return code in the called form and have it acted on
when control is returned to the calling form.

Is there a technique that I can use that would allow me to have a routine in
the called form change the content of a control in the calling form without
returning control to the calling form?

.... Thom
__________________________________________________ _
Thom Little - www.tlanet.net - Thom Little Associates, Ltd.

[Marc Gravell]

Probably the best option is an event - i.e. the second form has a "Foo"
property and a "FooChanged" event; the original form subscribes to the
event, and when it gets fired updates itself. That way, you get good
separation between the forms, and you can re-use the second form from
other callers and have them behave correctly.

Marc

[Thom Little]

I still don't see how to access a label (or event) in one form from another
form.

Can you point me towards an example?

Thanks for the help.

.... Thom
__________________________________________________ _
Thom Little - www.tlanet.net - Thom Little Associates, Ltd.

[Marc Gravell]

You need to expose via properties:
using System.Windows.Forms;
using System;
class Form1 : Form
{
protected override void OnLoad(System.EventArgs e)
{
base.OnLoad(e);
// load second form
Form2 other = new Form2();
other.SomeEvent += new EventHandler(other_SomeEvent);
other.Show(this);
}

public Form1()
{
Text = "Form1";
}
void other_SomeEvent(object sender, EventArgs e)
{
this.Text = ((Form2)sender).SomeProperty;
}
}
class Form2 : Form
{
TextBox tb;
Button send;
public Form2()
{
Text = "Form2";
tb = new TextBox();
send = new Button();
send.Text = "Send";
send.Click += new EventHandler(send_Click);
send.Dock = DockStyle.Bottom;
Controls.Add(tb);
Controls.Add(send);
}

void send_Click(object sender, EventArgs e)
{
if (SomeEvent != null) SomeEvent(this, EventArgs.Empty);
}

public string SomeProperty
{
get { return tb.Text; }
}
public event EventHandler SomeEvent;
}
static class Program
{
static void Main()
{
Application.EnableVisualStyles();
Application.Run(new Form1());
}
}

[Peter Duniho]

On Mon, 14 Apr 2008 13:57:50 -0700, Marc Gravell <ma**********@gmail.com
wrote:

You need to expose via properties:

Alternatively, you could pass the new value in an EventArgs-derived
parameter for the event.

Using Marc's code as a starting point (including the lack of a namespace
declaration :) ):

using System.Windows.Forms;
using System;

class PropertyChangedEventArgs : EventArgs
{
public readonly string Property;

public PropertyChangedEventArgs(string Property)
{
this.Property = Property;
}
}

delegate void PropertyChangedEventHandler(object sender,
PropertyChangedEventArgs e);

class Form1 : Form
{
protected override void OnLoad(System.EventArgs e)
{
base.OnLoad(e);
// load second form
Form2 other = new Form2();
other.SomeEvent += other_SomeEvent;
other.Show(this);
}

public Form1()
{
Text = "Form1";
}

void other_SomeEvent(object sender, PropertyChangedEventArgs e)
{
this.Text = e.Property;
}
}

class Form2 : Form
{
TextBox tb;
Button send;
public Form2()
{
Text = "Form2";
tb = new TextBox();
send = new Button();
send.Text = "Send";
send.Click += new EventHandler(send_Click);
send.Dock = DockStyle.Bottom;
Controls.Add(tb);
Controls.Add(send);
}

void send_Click(object sender, EventArgs e)
{
PropertyChangedEventHandler handler = SomeEvent;

if (handler != null)
{
handler(this, new PropertyChangedEventArgs(tb.Text));
}
}

public event PropertyChangedEventHandler SomeEvent;
}

static class Program
{
static void Main()
{
Application.EnableVisualStyles();
Application.Run(new Form1());
}
}
Either way would work and either is acceptable IMHO. The trade-off is
mainly whether you want to create a new property, or a whole new EventArgs
and delegate type for the event.

Pete

[Marc Gravell]

including the lack of a namespace declaration

Hey! 'tis just a demo...

, or a whole new EventArgs and delegate type for the event.

An option here would be to create an EventArgs<T: EventArgs with a
single T Value; for the delegate you can use EventHandler<T- but it
is a little clumsy:

public EventHandler<EventArgs<string>Foo;

etc

[Peter Duniho]

On Mon, 14 Apr 2008 15:05:37 -0700, Marc Gravell <ma**********@gmail.com>
wrote:

>including the lack of a namespace declaration

Hey! 'tis just a demo...

Not complaining, mind you. Some times it's useful to leave something as
an exercise for the reader. :)

>, or a whole new EventArgs and delegate type for the event.

An option here would be to create an EventArgs<T: EventArgs with a
single T Value; for the delegate you can use EventHandler<T- but it
is a little clumsy:

public EventHandler<EventArgs<string>Foo;

Assuming:

class EventArgs<T: EventArgs { ... }

It seems to me that rather than using the existing System namespace type:

delegate void EventHandler<T>(object sender, T t);

One might do this:

delegate void EventHandlerByType<T>(object sender, EventArgs<Tt);

Or you could even just call it "EventHandler<T>", and make sure you get
the type from the relevant namespace (but since you'll necessarily wind up
with a fully qualified type name, and since the overloading of the type
name could be confusing, I think one might as well choose a unique name
for the type :) ).

That would avoid the clumsy syntax you described (and I agree, it does
seem clumsy that way :) ). It's not quite as flexible as providing the
entire "args" parameter type, but presumably this sort of generic pattern
would be used in very limited, simple scenarios such as this one anyway.

Pete

[Thom Little]

Thank you both for your help.

You gave me exactly what I needed to get this thing moving.

Thanks again.

.... Thom
__________________________________________________ _
Thom Little - www.tlanet.net - Thom Little Associates, Ltd.