Kevin,

>>(And Bonnie, correct me if I'm wrong - I vaguely recall months ago that there were instances where the line that does the instantiation wasn't necessary...that I only had to do MyLocalData.DtCustomers ...I tried that and wasn't able. Am I mistaken?)

It has to be instantiated somewhere initially and then you shouldn't have to do it again. When you couldn't get it to work, perhaps it hadn't been instantiated initially when your app started up?

~~Bonnie



>Hi, Mike,
>
>I wanted to post a follow-up on your question of a second form accessing things (dataset, bindingmanager, etc.) that were created and part of the first form.
>
>John gave you a working solution of passing the necessary elements as parameters, and Bonnie provided a great stock answer on which to build a framework.
>
>There's one thing I'd like to add, partly because your question reminds me of many questions I asked and struggled with when I was learning .NET (which gave me a few grey hairs along the way!)
>
>The question was one of accessing different elements from one form to the next (be it datasets, collections, or even simple stuff like a signon user name/user ID which I'd store as a string and then display all through the app).
>
>Setting this stuff in one form and then passing it as parameters is one way to tackle it. Another way is to make different things 'public' so that one form can have visibility to another. For instance,
>
>

>MySecondForm oForm = new MySecondForm();
>oForm.dataGrid1.DataSource = myDataTableFromFirstForm;
>oForm.ShowDialog();
>

>
>There's another way, one that will seem a bit more complicated, but possibly better in the long run if you have a pretty data-intensive application. Basically, the approach is to identify up front all those things that may need to be utilized by multiple forms/containers, and place them in a class. That way, multiple forms can access the class, and you don't need to deal with adding parameters along the way.
>
>Here's a very basic example. Let's say I have a datatable that I create (or pull down from the business layer) called DtCustomer. It has one column, First Name. I add some records to it in one form. Then I pop up a second form that has a grid where I want to display the customers. (very basic, but I think it's close to what you asked).
>
>I can create a simple class called MyLocalData, where I define the datatable as a property. It could look something like this...
>
>

>using System;
>using System.Data;
>
>public class MyLocalData
>{
>	private static DataTable _DtCustomers;
>	public DataTable DtCustomers
>	{
>		get {return _DtCustomers ;}
>		set {_DtCustomers = value;}
>	}
>
>       // if you need to utilize a binding manager, or other data, you could add it here
>}
>

>
>Now, in Form1, maybe I want to retrieve some data, and then add a record to it. So I instantiate my MyLocalData class, and DtCustomers is available.
>
>

>MyLocalData oMyData = new MyLocalData();
>oMyData.DtCustomers = oBusinessLayer.RetrieveCustomers();
>DataRow Dr = oMyData.DtCustomers.NewRow();
>Dr["FirstName"] = "JOHN";
>oMyData.DtCustomers.Rows.Add(Dr);
>

>
>And finally, when you load form2 and define a grid to show the customers, you can do this...
>
>

>MyLocalData oMyData = new MyLocalData();
>dataGrid1.DataSource = oMyData.DtCustomers;
>

>
>You could do the same thing with a bindingmanager, if you need for multiple forms to have visibility to the same binding manager.
>
>It requires a bit more code and probably more overhead, and might even be over-kill if the app isn't a complex one. But if the app grows to the point where you're passing so many parameters that you feel you've 'boxed yourself in', this approach may be preferable.
>
>I think this is along the lines of something Bonnie said in a prior post, about treating DataSets in the similar way that one would work with business objects.
>
>I took a .NET class some time ago where the instructor basically said that anytime you declare a dataset or table or something in a form, ask yourself if it really 'belongs' in a form or as part of a class.
>
>Again, there are several ways to do this, and everyone needs to have a comfort level. I experimented with this for awhile when I learned it, and became comfortable enough to use it for production.
>
>(And Bonnie, correct me if I'm wrong - I vaguely recall months ago that there were instances where the line that does the instantiation wasn't necessary...that I only had to do MyLocalData.DtCustomers ...I tried that and wasn't able. Am I mistaken?)
>
>Hope this helps...
>Kevin