Printable View
Hello,
In Visual 6, MFC 4.2 I had AfxGetApp. I used it to get the application object from all other objects. In this class I added some fields and some set\get methods.
How can I do the same in Visual 2008, in C# ?
I'm looking for an elegant way to declare and use a singleton in C#.
Thanks.
This doesn't sound like a very good design to begin with. Having all of this global data around can lead to trouble, but implementing a Singleton in C# is much like doing it in C++, you would create a class with some static methods and pass around a single instance. Maybe if you told us exactly what you are trying to achieve we could suggest a more workable solution.
I have an application that basically has 3 different executables or "Apps" that can operate over it. There are certain properties that I wanted to abstract to operate on through out the application as a whole with out having to embed junk in the "App" itself. Essentially I just wanted the "same" application with some different settings. What I ended up doing was making an interface for the application and then having my "main" come up with an instance of the "App" it was suppossed to run and call Run. That way I can have several different "Apps" running over the same code base. Really worked out well for Unit Testing also.
I also have a static Settings class that holds onto the "App" object so that it can be referenced by the libraries.
So, I'm unclear; are these three different programs or is it one program using different settings? If it is the latter, this is all you need.
http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx
They are three completly different programs 2 of which are services and countless more debug applications which save us a ton of time not waiting for the whole kit and kaboodle to start up. It is more than "settings" although that is what I call it. Each app has unique ways of handling things such as inputs, output, and many other things. It worked out best for us to abstract an "App" object so that we could quickly create new "Apps" and override specific behaviours of the application.
I don't know, it seems really weird. Is this something that cannot be solved by simple polymorphism within a single application? Seems like you are describing that exactly but at the level of an executable instead of a class/interface level.
You are right it basically is polymorphisim at the Executable level. We lay out the ground work to start up the application and then execute some application specific methods. In theroy it could all be solved in one application but there are a couple problems with that. To start with the entire application has nearly 30 projects in it, and the developer usually only needs a subset of those projects to work on a particular piece. In addition not all of the applications need all of the dlls that are associated with it If it put it all into one application then some versions would need to carry around dlls that they actualy did not need just because the different app needed them. It is merely about solving the problem of the massive size of the code base, I can see where you would think it is a little wierd, but it has really worked well for us because we can give a developer a very small "application" and is integrated into the whole without the developer needing the knowledge of the entire application.
Well, writing code is all about finding maintainable solutions that work. If you got that, cheers :)
In C# Winforms you can create a singleton class.
In C# WPF you can use the Application object. The 'App' instance is available throughout.