Applications have special support in Windows Forms. This book chapter focuses on this topics in depth, and starts by defining what an application actually is.
Application Architecture in Windows Forms 2.0
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I see more and more Swing in this. Microsoft is slowly learning what’s best.
It’s quite nice to see Microsoft taking over the good things from Java and well as the other way around (Sun also going Generics etc.).
Java had Generics before C#. If you want examples of C# isms that have turned up in Java, have a look at Java Annotations.
One thing is clear, and that is that C# provides much needed competition to Java. I doubt that the more desktop oriented enhancements in Java 6 ever would have seen the light of day without it.
Don’t mean to be pedantic, but I’m not sure the article has anything to do with Swing versus C#. The article focuses on a very critical aspect of desktop application development. Which is how you handle the behavior of instances of your desktop applications. Do you want a SDI application with multiple instances connected to single runtime, or loop, or service (like the .NET one in the article). Or do you want an MDI application with only one instance and one runtime (e.g Singleton object). In GNOME and KDE, the equivalent services that provide these functionality will be, environment variables, DCOP, Bonobo and more recently DBus. .NET provides these capabilities in its libraries and the article discusses the various implementations. If I got anything from the article, it is that C# is an annoyingly verbose language, just like Java is. I guess Python has spoilt me. 🙂 I won’t be writing any GUI app in C# anytime soon, unless I’m paid to do so.
Edited 2006-06-12 10:02
I see more and more Swing in this. Microsoft is slowly learning what’s best.
Actually the idea of a global Application class is taken straight from Delphi, where it’s existed since the earliest versions. This is hardly surprising: the creator of Delphi, Anders Hejlsberg, is also the creator of C#.
Java/Swing is not the ideal GUI development system. While it’s impressively extensible, creating GUIs in it requires an excessive amount of boiler-plate code. This is particularly true of registering listeners for events: C#’s delegate system (based on Delphi’s object pointers) and Qt’s signal/slot mechanism are both superior approaches.
That said, C# is innovating in other areas: in particular it is working hard to bring object-orientated and functional programming concepts into the mainstream, and that is a good thing. What is also a good thing is that Java is actively trying to keep up, giving developers a good choice of development platforms.
A global application class (which is a cyclic-dependency waiting to happen, and has encouraged millions of people to create such applications) is not first seen in Delphi: Microsoft’s MFC existed before Delphi, and while there weren’t many static methods in the CWinApp class, MFC provides convenient access to the global variable that holds a pointer to it. I forgot (it’s been 9 years since I used OWL, and longer since I used Borland’s TurboVision frameworks for DOS) whether OWL and TurboVision had a global scope instance of the application class. The BeOS C++ API has a global variable as well for the BApplication class. I’d be surprised if there aren’t earlier examples of global access to the application class, in C++ frameworks as well as any other languages before or after it.
In no way is this a “good thing” to have global access to the application class: people start getting the idea that calling from somewhere outside the application class into the application class for some functionality is a good thing, when what it really does is create an application that gets snarled in cyclic dependencies. The only method/routine that should ever call into the application class besides main() is the application class itself: there should be no global variable everything has access to. The application class should be used to control the rest of the object-oriented portion of the system with the same rules of use and access as main() in a straight C program: nothing calls it, and it depends on everything else. Any other designed usage model is flawed. When is the last time you saw a C application that called into main() from some other routine?
Having said all that, if you treat the entire frameworks (such as MFC, OWL, Swing, etc.) for an application as the lowest level dependency, and you don’t call into methods of a derived application class from another class, such that you don’t need to #include the declaration for the class derived from the application class, you can pretend that things are perfectly fine, and just label that as the blob of compiler libraries that your application depends on, and it won’t too negatively affect your ability to test classes of your application separately and expand your application without dragging in extra dependencies that shouldn’t be needed. As soon as you have a need to #include the headers to your derived application class so that another class uses it, you’ve just created a big snarled mess that is impossible to reuse without hacking it into another application, and you can no longer test that class as a unit, because that class now depends on the rest of the application, directly or indirectly. This also leads to much longer compile and link times as well; this is language-independent for the bad effects it has.
For a far more detailed explanation of all this sort of thing and how to fix it, read the book “Large-Scale C++ Software Design” by John Lakos, and don’t consider it’s only a C++ problem at all: the Java libraries often have the same problems, as do other languages that allow more than a single class/method/file and forward declarations.
So, by making all the methods of the Windows Forms C# class static, they’ve effectively made the Application class global, and strongly encouraged people to construct similarly goofed up designs that have become the normal practice. If they could have made the language such that (for example, in C++) the main() method was a friend method, and everything else was private, that would have made things clear that the only place to set global system settings for an application is within the main() method for initialization, and the application class would control the flow of the rest of the application.
For some reason, I can’t edit my last comment, as there’s no link displayed… I should have typed in the last sentence:
“If they could have made the frameworks such that (for example, in C++) the main() method was a friend method, and everything else was private or protected (to create classes derived from the application class) and not have a static/global application class variable, that would have made things clear that the only place to set global system settings for an application is within the main() method for initialization, and the application class would control the flow of the rest of the application.”
A cleaner way of doing this, without including the Visual Basic DLL, would be to create an application-level mutex. I know you can do this using the Win32 “CreateMutex” call, which I imagine is available in C# in one form or another.
Overall, though, it’s an interesting article.
A cleaner way of doing this, without including the Visual Basic DLL, would be to create an application-level mutex. I know you can do this using the Win32 “CreateMutex” call, which I imagine is available in C# in one form or another.
System.Threading.Mutex which is in the framework, although interop will get you the native win32 call.