Richard_AU wrote:
Thank you everyone for your assistance I now understand how to use this
events mechanism.
I got it to work but there is a little problem.
I can make it work if I create another form and from that form I load my
"controller " class.
How can I load my "controller " class when the application starts?
You mean, how do you get your controller class to actually be able to
act as the controller class, instead of the controlled class? :)
This is simple to do, once you understand the structure of the default
C# program when created within Visual Studio. The entry point for your
program is the Main() method found in the Program class, which is in the
Program.cs file. Check your Solution Explorer pane to find this easily.
In the Main() method, you'll want to change the code that by default
looks something like this:
Application.Run (new Form1());
Instead, you'll probably want to do something like instantiate the
controller class, let it instantiate your initial form, let the
controller class subscribe to whatever events are appropriate at the
time, and _then_ call Application.Run () with the form instance that the
controller created. You could even have the controller class itself
make the call to Application.Run (), which could give it a little more
control over application shutdown. Or you could have a method in the
controller class that returns the initial form.
Or, you could even have a static method in the controller that does all
of the instantiation of the controller and the initial form and then
returns that initial form.
If you did the latter, then the only change to the Program.Main() method
might look something like this:
Application.Run (Controller.For mStartup());
where the Controller.Form Startup() method creates the actual controller
instance, creates the initial Form instance, subscribes the controller
instance methods to the initial Form's event as necessary, and then
returns the reference to the Form instance.
Now, all that said...
For yet another perspective on how this might work: I don't think it'd
be the end of the world if you just wanted the initial form's
constructor to instantiate the controller. Yes, it would mean that the
controller itself isn't really doing the instantiation of the initial
form, which seems a little backwards. It also means that the form class
winds up perhaps knowing more about the controller than would normally
be the case. But as long as the controller semantics are otherwise
adhered to, I don't think that devalues the use of a controller class.
In fact, if you make the controller a singleton class with the usual
static Instance property, you can either instantiate the controller
lazily (on the first call to the Instance property getter), or in a
static constructor for the class. Either way would allow you to not
only leave the default Program.Main() method as-is, but would also avoid
having the controller's instantiation explicitly tied to code within
your initial form; _any_ form that ever accesses the controller class
could be used and the controller class would get created implicitly in
the process.
So, for example, you might design it so that rather than the controller
class creating that initial form, the form "registers" itself with the
controller in its constructor, allowing the controller to at that time
do whatever event subscription, etc. it needs to do. You could in fact
make that the design for all forms; controlled instances always need to
register themselves, which is the point at which the controller then
hooks up whatever event handling, etc. it wants.
IMHO, "design patterns" such as singleton, controller, etc. are for your
benefit. Adhering closely to them is often the best way to get the most
value out of them, but if there seems to be a benefit in deviating a
little from the pattern, and you can do so knowing exactly what
implications that has with respect to the overall design, I don't think
it's terrible to do so. Better to deviate a little, than to corrupt
some other part of the design just to get the design pattern to be exact
(not that I think that changing Program.Main() is a corruption...in this
case it's just a matter of what seems easier or cleaner to you).
Pete