This post originated from an RSS feed registered with .NET Buzz
by Brad Wilson.
Original Post: CAB, June to October: CabApplication and Family
Feed Title: The .NET Guy
Feed URL: /error.aspx?aspxerrorpath=/dotnetguy/Rss.aspx
Feed Description: A personal blog about technology in general, .NET in specific, and when all else fails, the real world.
Part of our work in re-working the application startup sequence caused us to create a small hierarchy of classes inside of CAB to represent different styles of CAB applications.
~ ~ ~
The top three classes in the hierarchy are classes you're not likely going to derive from for normal CAB applications: CabApplication, CabShellApplication, and WindowsFormsApplication.
At the top is CabApplication. This is the workhorse of the hierarchy. It's a generic class, which takes the type of the root WorkItem as its generic parameter. It knows all the required services and strategies to get a CAB application up and running. If you ever need answers about what happens when a CAB application, the Run() method reveals all. :)
Directly below that is CabShellApplication. This is an extension of CabApplication to support any style of application that runs with a shell. It adds a second generic parameter, which is the type of the shell. It extends the startup sequence in CabApplication to support creating the shell at the right time.
The WinForms project contains a class called WindowsFormsApplication. This class knows all the necessary logic for Windows Forms-style applications. It understands, for example, when to call Application.EnableVisualStyles, and which builder strategies and services are required for Windows Forms-based applications.
~ ~ ~
Derived from WindowsFormsApplication are the two classes that you are likely to use as your application base class: FormShellApplication and ApplicationContextApplication.
FormShellApplication will be used for applications that are traditional smart client applications with a main shell form. It knows to call Application.Run() with your form, for example. For most CAB applications, this is going to be the class you'll use as your base class.
ApplicationContextApplication looks very similar, and is used for applications which start with a context instead of a form. This allows more flexibility in defining what it means for your application to be done running. One example of why you might choose this style of application is because you have the potential to have many main windows open at once (for example, a web browser). It doesn't matter which window was opened first; as long as at least one is still open, your application is still running.
~ ~ ~
Because the CAB application hierarchy offers a lot of flexibility, you could "plug in" your own custom application classes that behave differently from ours. We would be interested in hearing if you make your own custom application class hierarchy!
Previous Topic
