Dear Ahmet,
.NET contains all sorts of stuff to play around with types, forms and
variables and stuff without knowing too much about them. If you know the
name of a Type in .NET you can find out anything about it, create instances
of it and set values, execute methods, etc, etc. This is all given by the
System.Type and System.Reflection namespaces. It's wonderful!!
When you look at the help info on these it's daunting to say the least.
It is however very simple once explained.
Your problem as I understand it is that you have various form names in a
database and you want to get these forms up and running with only the name
as your starting point. No problem using Reflection
A form's name is it's class name. And a class name is a Type name. Or
near enough. Let's say you have a form called frmFoo. And this is defined in
your application's namespace which will be something like Akgun.WonderApp.
The full type name of your form will therefore be Akgun.WonderApp.frmFoo.
Now if you plug that name, as a string, into Type.GetType(), you'll get a
Type object - which is something that you can use to create an instance of
the form.
So:
sFormName = <Obtain form name from database>;
Type oFormType = Type.GetType ("Akgun.WonderApp." + sFormName);
Now the next part depends on whether your forms' constructors have
parameters or not.
If there are no parameters, ie. you have simply
public frmFoo() {
InitializeComponent();
: : :
}
then you can get your form up in one (complex) line.
((Form) oFormType.GetConstructor (System.Type.EmptyTypes).Invoke
(null)).Show(); // Display form..
Let's break this down. This is the long version:
ConstructorInfo oConstructorInfo = oFormType.GetConstructor
(System.Type.EmptyTypes);
Form oForm = (Form) oConstructorInfo.Invoke (null);
oForm.Show();
Every Type can provide, amongst many things, information about the
constructor or constructors that are available with the type.
GetConstructor() takes an array of the Types of the arguments to the
constructor - part of its "signature" - with which it matches against all
the constructors for that type. System.Type.EmptyTypes is simply an empty
Types array signifying that we want the constructor with no parameters.
Having got the constructor info object, we can ask it to create an
instance of the type that it knows about - in this case the required form.
That's the job of Invoke() and the null is there because the constructor
takes no arguments. The value returned is an instance of your form which is
cast and assigned to a Form variable.
Form oForm = (Form) oConstructorInfo.Invoke (null);
is the equivalent of
Form oForm = new frmForm()
except, of course, that frmFoo is not mentioned anywhere.
Ok. That's how it works if you have no arguments for your form's
contructor. In case there are args, and for anyone interested, here's a more
complex version.
Let's say that this time we're dealing with frmBar which has the
following constructor
public frmBar (integer i, double d) {...}
This time we can't use a one-liner to do the job:
Type[] aoArgTypes = new Type[2] {Type.GetType ("System.Int32"),
Type.GetType ("System.Double")}; //Fussy about names.
ConstructorInfo oConstructorInfo = oType.GetConstructor
(aoArgTypes);
Object[] aoArgs = new Object[2] {(System.Int32) 1, (double) 2};
//Not fussy.
Form oForm = (Form) oConstructorInfo.Invoke (aoArgs);
oForm.Show();
You'll see in the second line that we are again getting a constructor
info object. But this time we actually have some arguments which must be
specified. That's done in the first line and you'll notice that while frmBar
takes an integer, GetType() requires a string containing the full .NET name,
"System.Int32". Likewise for double.
The third line creates an array corresponding to the array of types, but
this time with the actual argument values. This array is then given to
Invoke() so that the constructor has some values to play with.
Easy, huh?
I would recommend having form constructors with no arguments because
that makes it dead simple using the first example. Having arguments will
involve storing type names and values in the database and packaging them up
for GetConstructor() and Invoke(). Nah, don't want to bother with that,
thanks.
A final note. Hard-coding "Akgun.WonderApp." is not best practice. As
your empire expands, you might change the namespace to
Akgun.Apps.Database.WonderApp and forget to change the corresponding string.
It's possible to get the name from the assembly. I'll leave that as an
exercise.
Best wishes,
Fergus.
