Application Context

  • Thread starter Thread starter Norvin Laudon
  • Start date Start date
N

Norvin Laudon

Hi,

I have an application that has a form and a few classes. Rather than the
form being the startup object "Application.Run(new Form1())", I would like
one of the classes to be the startup.
The startup class would then contain an instance of the form, to use as it's
UI.

To do this (and correct me if I'm wrong), I believe I need to create an
ApplicationContext object, and pass that to the Application.Run() method?

If so, does anyone have a sample of doing this, or some skeletal code? I
can't seem to find very good examples on the web. Which usually means I
might be on the wrong track...

TIA,
Norvin
 
Norvin said:
I have an application that has a form and a few classes. Rather than the
form being the startup object "Application.Run(new Form1())", I would like
one of the classes to be the startup.
The startup class would then contain an instance of the form, to use as it's
UI.

To do this (and correct me if I'm wrong), I believe I need to create an
ApplicationContext object, and pass that to the Application.Run() method?

If so, does anyone have a sample of doing this, or some skeletal code? I
can't seem to find very good examples on the web. Which usually means I
might be on the wrong track...
Click to expand...

I assume that what you want is to avoid application exit when main form
is closed. You can get example here:
http://www.nedcomp.nl/support/origd...mwindowsformsapplicationcontextclasstopic.htm
 
Hi Vad,

Thanks for the link, but it just links to the MSDN "ApplicationContext"
topic in the documentation. Did you send the wrong link?

It seems wrong to me to have an application whose UserInterface (a form!) is
the parent of all the various classes in the project. Is this unusual?

Thanks,
Norvin
 
Norvin said:
Hi Vad,

Thanks for the link, but it just links to the MSDN "ApplicationContext"
topic in the documentation. Did you send the wrong link?
Click to expand...

It is different from the one on microsoft site in that it contains
example of usage of context to create application with more flexible
exit control.
It seems wrong to me to have an application whose UserInterface (a form!) is
the parent of all the various classes in the project. Is this unusual?
Click to expand...

Why? I believe that 90% of all applications fillow to "main window"
conception. when you open a Word, a Outlook, <anything else here>, you
have a main window, and usually some child windows, or MDI.

If you tell what you want to achive in a long run, it would be easier to
give advice because "I would like one of the classes to be the startup"
barely can be the goal, rather a way to achive the goal :)

Vadim Chekan.
 
Hi Vad,

Thanks for taking the time to respond.

Vadim Chekan said:
It is different from the one on microsoft site in that it contains
example of usage of context to create application with more flexible
exit control.
Click to expand...

Sorry, I didn't realize it was different than MSDN, I'll take another look
at it...
Why? I believe that 90% of all applications fillow to "main window"
conception. when you open a Word, a Outlook, <anything else here>, you
have a main window, and usually some child windows, or MDI.

If you tell what you want to achive in a long run, it would be easier to
give advice because "I would like one of the classes to be the startup"
barely can be the goal, rather a way to achive the goal :)
Click to expand...

OK, some details: I'm programming an application that interfaces with a
piece of machinery. The machine places items under an xray camera and
signals my program.
My program then snaps a picture of the items, and sends them off across the
network (via remoting) to a server. Sometime later, a decision on the image
comes back from the server, which my program then relays back to the
machinery.

In other words, there is very little human interaction. The UI is just there
for displaying a few status items for troubleshooting. All of the logic is
activated by other devices external to the program (the server, or the
machinery)

It would make sense to me to structure the program in the following way:
- have a main class (the startup class) which oversees all of the logic,
keeps track of what's been sent where, etc
- as members of this main class, have child classes to interface to the
server, the machine, and also a child class (form) for the UI

Do you agree with this general structure?

(As I typed this message, I realize that my typical application probably
differs from most in here, as there is typically no user interaction
required)

Thanks,
Norvin
 
OK, some details: I'm programming an application that interfaces with a

[cut]
(As I typed this message, I realize that my typical application probably
differs from most in here, as there is typically no user interaction
required)
Click to expand...

Well, now i see the point. You want to implement mostly windowless
application. Then ApplicationContex should be solution and I hope link I
gave you help.

But consider how user will call you application if he will want it. Or
how user will be able to shutdown (restart) your application. Probably
icon in notification area? Then I see it as something like this:
-----------------------
Form1 f = new Form1();
ApplicationContext cx = new ApplicationContext();
f.notifyIcon1.Click += new EventHandler(f.notifyIcon1_MouseDown);
Application.Run(cx);
---------------------
Then there will be no window (main window) after application start, only
icon in a notify area, and user will be able to call window only when
needed.

Vadim Chekan.
 
Back
Top