Best practice to pass information between windows.forms

Question

What do you do to pass information between forms? Forward is straight forward (sorry) using Properties or maybe parameters in a New() or DoStuff() method, but what about sending something back when the user is done with the second form? (IE. ID of the item selected) We have used all these:

• Passed the calling form into the called form as a ref so the called form could access properties or methods on the calling form. I really don't like this because the two forms are very dependent of each other. Passing the calling form as a object only slightly improves this.
• Use Events This somewhat decouples the code, but the signatures must match on the event handler.
• Use an Public Interface I'm talking about the .NET built in one, but I suppose you could create your own. This seems like the best to me.

Now raise the bar, what if the forms are in two different DLLs? As long as the forms are not dependent on each other, I would think this wouldn't be a big step.

Answer 1

Do you want to access the UI elements of the second form? I think a cleaner way is to using a shared object for passing the data back to the calling form. Pass the object as a parameter to the second form constructor, which can populate the instance fields and return that instance to the calling form. This object can also raise any events (like property change events) to notify the calling form (or subscribers) if required.

Answer 2

If it's a matter of a main form creating an instance of another form, waiting for the form to do some work and then close, and checking it's result, then having public properties or listening for events makes the most sense. Neither of these things would be impacted by having the forms in different assemblies. You do get an explicit binding contract between the two forms, but if the properties were described (as you suggest) in a public interface, than as long as everyone agrees to the terms of the interface, you're good.

I'm not sure how much more complicated you'd want this to get. In the past I've used a static singleton object for holding application state. The app-state object would expose event handlers that other parts of the program could listen to. The main form would create the app-state (just get a reference to it really) and listen to certain events on it. Then the main form would create child forms and controls to do work. The children would change properties of the app-state object, which would in turn fire events that the primary form would listen for. This way the various forms and controls were decoupled from each-other. The downside is that they were tightly couple to the app-state singleton.

Answer 3

Create public properties for the form, then wait for the form to close and check the properties before disposing the new form.

NewForm myForm = new NewForm();
myForm.ShowDialog();
string x = myform.MyProperty;

Answer 4

One thing I had success doing was to create a lightweight publish / subscribe eventing system in the application. This was in .net 1.1 and not sure how it would change with generics. Essentially we had a singleton which contained a hashtable with a string key, and multi-cast delgates.

The singleton had methods like RegisterForEvent(string key, delegate handler), RaiseEvent(key,data) etc...

We then defined a standard delegate and said all users must implement this pattern for example our handlers had to be: void method(object sender, CustomEventArgs args). Publishers would define their own derived class of CustomEventArgs.

The nice thing is this allowed a completly decoupled system to be built. We had many assemblies and didn't have any issue just need to ensure your eventargs are defined where other subs could get at them.

We had what we called different subsystems for example we had one which monitored the internet connection and when it raised an event, the UI would change to indicate the status of their connection, we also had a queueing service which would post messages to the server, when it saw the connection dropped we would stop posting.

The downside is it is very looseley coupled at least our implementation was but there are ways to improve upon that.

Answer 5

I have found that once you have a well designed Domain Entity Object Model or simply business objects. These tasks become much easier.

If you dont have Domain Entities such as Employee, Account, Location etc., you find yourself writing forms with a bunch of properties and create tons of awkward dependencies. Over time this can be very messy.

Once you have the Domain Entity in place things are much easier to deal with. For example, to edit your Employee using a form you can simply create an Employee property like this:

NewForm myForm = new NewForm();       
myForm.Employee = employeeToEdit; // This can have state 
myForm.ShowDialog(); 
Employee editedEmployee= myform.Employee;

EmployeeFacade.SaveEmployee(editedEmployee); // Or whatever

Regarding Events, for Winform/WPF apps it it almost aways helpful to create a global EventManager using publish / subscribe pattern to handle communication between forms. It is very rare I will ever have one form 'talk' directly to any other form. That is another topic so I will not go into detail, if you want examples I can provide several I have done.

Raiford Brookshire

Answer 6

this.Hide(); string[]name = new string[]; new frmFormName = new frm(string what, string you, string going, string to, string put, stiring in); this.ShowDialog(); this.Show();