c# Winforms with classes.

[Cliffordagius]

Hi, I have a winforms project with multiple forms that are children of a parent form using the MDI format. Now my main form which is the parent of all the others has a class instance created in the code to do some comms work. My issue is thatI want to be able to access some of the methods and properties of this instance from my other child forms to for example change some settings etc. Can someone point me in the right direction please. example of the code in Main.cs myClass mainClass = new myClass(); In admin.cs I want to access the PacketSize property of the myClass instance that is created in the Main.cs Can this be done please say yes... Cliff.

[Lost User]

Cliffordagius wrote:

Can this be done please say yes...

Yes. Have your class implement a custom interface, and cast the form to it's correct interface when you need to access the properties specific to the interface.

Bastard Programmer from Hell :suss:

[Luc Pattyn]

I say: yes Furthermore I suggest you choose, buy and study an introductory book on C#, it will teach you the basics of the language and relevant OO principles. :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

[Lost User]

Declare you mainClass instance at the form level and expose the instance as a property.

internal MyClass MyClass {
get {
return myClass;
}
}

And from the child forms you can access this class like this:

MainForm mainForm = this.MdiParent as MainForm;
if (mainForm != null) {
var packetSize = mainForm.MyClass.PacketSize;
}

[BillWoodruff]

Note: having the information about exactly where 'mainClass, and admin.cs instances are created would, imho, focus this question. This type of question involving exposing fields, methods, etc. across Form boundaries is one of the most frequently asked and answered ones on the C# QA forums. There are a variety of techniques you can use. 1. injection : have a public variable in admin.cs that holds the instance of mainClass: and when mainClass is created/instantiated: set that public variable in the instance of admin.cs. Note the requirements here: some entity (your main form's code ?) will have to have access to instances of both admin.cs and mainClass. 2. expose the instance of mainClass via a public static property in whatever Form it is created in; using a private 'setter, and a public 'getter is a common practice. 3. create a static class to function in the same way as #2, but, then, why do this, if you only need to expose one instance of one object ? However, if mainClass is instantiated in one semantic entity, and admin.cs is instantiated in another, then this strategy may be necessary. 4. raising events: not relevant here, I think. My own preference is to keep the "scope" of what is exposed as minimal as possible (which is I why I shudder in horror every time I see .NET code that injects the instance of an entire Form into another). I see this as being consistent with the principle of "separation of concerns." In this case, if the only data "admin.cs" must have is the 'PacketSize data from mainClass: then consider just exposing a static property, or variable of whatever Type PacketSize is in whatever Form creates the instance of mainClasss, and setting it immediately after mainClass is instantiated. Then admin.cs can access the property by something like mainClass.PacketSize. If PacketSize is something dynamic that's changing, then use a public static method in mainClass.cs, perhaps to access the current value from the instance of admin.cs. You'll note I have not mentioned interfaces here: I have a bias against using them in cases where the real use of them is only to expose limited access to data via casting to the interface. edit ... see response to Shameel's code above for an example of what this post talks about in code ... best, Bill

"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle

[BillWoodruff]

Picky-picky: the use of identical names, for both Property Type, and Property Name, in the 'internal Property definition above ... uhh ... makes me nervous :) Yes, it will compile, but I think that then becomes ambiguous code that degrades future maintainability. Consider: we define 'MyClass this way:

public class MyClass
{
// default 'ctor
public MyClass() {}

// 'ctor where PacketSize is passed in as a parameter
public MyClass(int pSize)
{
    PacketSize = pSize;
}

public int PacketSize { get; set; }

}

Then, in the "main form:"

private static MyClass myClassInstance1;

public static int PacketSizeInMyClass1
{
get
{
return myClassInstance1.PacketSize;
}
}

AdminForm adminForm = new AdminForm();

private void MainForm_Load(object sender, EventArgs e)
{
myClassInstance1 = new MyClass(256);

adminForm.Show();
}

Now, in the instance of 'AdminForm, we can directly access the PacketSize value in the instance of MyClass:

int pSize = MainForm.PacketSizeInMyClass1;

This is only one variation of many possible approaches to narrowing the scope of what is exposed, and eliminating complex look-ups (as in your example, where you have to re-create the instance of MainForm by de-referencing this.MDIParent every time you want to access the value of PacketSize). And, each scenario's requirements may demand different approaches: if, using the scenario above there is one and only one instance of MyClass ever created: then that class can be made static, and the code simplified futher. In the example here, we've gone to perhaps awkward lengths to leave MyClass a dynamic class that could have more than one instance created (although, obviously, we haven't shown any other instantiation and its use).

"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle