How can I do the following...
-
I have an application, that needs to have a settings dialog. I want the settings to be available to the rest of the application all the time, even when the settings dialog is closed. In other words, this dialog is merely a utility for the user to modify these settings and save them. I'm thinking, I should have the settings struct, so that it's a value type, which doesn't need instantiation to be used, and be available all through the application lifetime. Now the challenges are: 1- What's the best method to load/save this struct? Can XML serialization work here? If so, how? 2- Can I bind the struct's fields/properties to controls on the settings dialog, so that any modification will automatically reflect in the struct, which, in turn is the one responsible for actually loading/saving all the settings? Thank you. Sammy "A good friend, is like a good book: the inside is better than the cover..."
-
I have an application, that needs to have a settings dialog. I want the settings to be available to the rest of the application all the time, even when the settings dialog is closed. In other words, this dialog is merely a utility for the user to modify these settings and save them. I'm thinking, I should have the settings struct, so that it's a value type, which doesn't need instantiation to be used, and be available all through the application lifetime. Now the challenges are: 1- What's the best method to load/save this struct? Can XML serialization work here? If so, how? 2- Can I bind the struct's fields/properties to controls on the settings dialog, so that any modification will automatically reflect in the struct, which, in turn is the one responsible for actually loading/saving all the settings? Thank you. Sammy "A good friend, is like a good book: the inside is better than the cover..."
A singleton pattern works well for this. We use a
PropertyGridfor the time being in our application. I create a singleton that uses a collection of classes implementing theICustomTypeDescriptorand gets everything from a database. The application allows the changing of these values while callers throughout our application have a simple means to get these values. Just put the classes in an assembly that is shared and used by all the assemblies in your application. I put ours, for example, in our toolkit assembly. XML Serialization would be a good way to read and save your preferences. Just see theSystem.Xml.Serializationnamespace for all the attributes you can use, as well as theXmlSerializerthat does include a sample of how to use it. It's really very simple.Microsoft MVP, Visual C# My Articles
-
A singleton pattern works well for this. We use a
PropertyGridfor the time being in our application. I create a singleton that uses a collection of classes implementing theICustomTypeDescriptorand gets everything from a database. The application allows the changing of these values while callers throughout our application have a simple means to get these values. Just put the classes in an assembly that is shared and used by all the assemblies in your application. I put ours, for example, in our toolkit assembly. XML Serialization would be a good way to read and save your preferences. Just see theSystem.Xml.Serializationnamespace for all the attributes you can use, as well as theXmlSerializerthat does include a sample of how to use it. It's really very simple.Microsoft MVP, Visual C# My Articles
Heath Stewart wrote: singleton pattern I'm sorry, but I don't know what that is :( Heath Stewart wrote: Just put the classes in an assembly... So you do suggest classes instead of structs? I read in an article on CodeProject before by Nishant that whenever you find that you're using a class merely to store values, it's better to use a struct. Comments? Sammy "A good friend, is like a good book: the inside is better than the cover..."
-
Heath Stewart wrote: singleton pattern I'm sorry, but I don't know what that is :( Heath Stewart wrote: Just put the classes in an assembly... So you do suggest classes instead of structs? I read in an article on CodeProject before by Nishant that whenever you find that you're using a class merely to store values, it's better to use a struct. Comments? Sammy "A good friend, is like a good book: the inside is better than the cover..."
A singleton is a single instance of an object. You can either use a simple approach like:
public sealed class MySingleton
{
private static MySingleton instance;
private int i;
private MySingleton()
{
i = 1;
}
public static MySingleton Instance // Often private, though
{
get
{
if (instance == null)
lock (typeof(MySingleton))
if (instance == null)
instance = new MySingleton();
return instance;
}
}
public static int SomeMethod()
{
return Instance.i; // Use Instance, not instance to make sure it's init'd.
}
}Or you could use a
ContextBoundObjectwith its ownRealProxyderivative that returns the same instance when someone tries to instantiate your object.Microsoft MVP, Visual C# My Articles