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
