Creating Tools > Options window
-
I am strugling with creating an Options Window (like how you go to Tools > Options and a window pops up with options in it). Does any one know of a way to create this type of windows? Any Ideas, link to an article / white paper etc will be highly appreciated. Thanks.
-
I am strugling with creating an Options Window (like how you go to Tools > Options and a window pops up with options in it). Does any one know of a way to create this type of windows? Any Ideas, link to an article / white paper etc will be highly appreciated. Thanks.
Just create a new form with the options, and from your main form button/menu item click/whatever, call it up. Nothing much really to it.
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
-
I am strugling with creating an Options Window (like how you go to Tools > Options and a window pops up with options in it). Does any one know of a way to create this type of windows? Any Ideas, link to an article / white paper etc will be highly appreciated. Thanks.
The window's not hard, you do that like any other window. What you need to decide is what all you will show, how you will store choices, and how the rest of you app reads and responds to those choices. I assume that's what you're talking about. I don't know of an article specificly dealing with that, though many may have something like that built into articles about other topics. Personally, I'd use XML serialization: decide what options to offer, build an XML structure to house them, make your options form address those options, read your config, and write to it. Then I'd probably have the host form show it as a dialog [
optwin.ShowDialog()], and make it expose your XML serializable config object as a property so that the host can get the options directly from the options form. And make your host form look for the config on load to initially respond to saved options. But there are a number of things to consider and work out with this. Clear as mud?
Try code model generation tools at BoneSoft.com.
-
The window's not hard, you do that like any other window. What you need to decide is what all you will show, how you will store choices, and how the rest of you app reads and responds to those choices. I assume that's what you're talking about. I don't know of an article specificly dealing with that, though many may have something like that built into articles about other topics. Personally, I'd use XML serialization: decide what options to offer, build an XML structure to house them, make your options form address those options, read your config, and write to it. Then I'd probably have the host form show it as a dialog [
optwin.ShowDialog()], and make it expose your XML serializable config object as a property so that the host can get the options directly from the options form. And make your host form look for the config on load to initially respond to saved options. But there are a number of things to consider and work out with this. Clear as mud?
Try code model generation tools at BoneSoft.com.
The window's not hard, you do that like any other window. What you need to decide is what
all you will show, how you will store choices, and how the rest of you app reads and responds to
those choices. I assume that's what you're talking about.Yes I am.
Clear as mud?
:) pretty much!! I have the settings for my applications stored in the MyApp.settings file. Would that be a bad idea? Also, when the settings are changed i.e. user has changed some stuff in the options window, the parent form doesn't autmatically apply the changes. For it to apply changes does it have to be "refreshed" or "reloaded"?
-
The window's not hard, you do that like any other window. What you need to decide is what
all you will show, how you will store choices, and how the rest of you app reads and responds to
those choices. I assume that's what you're talking about.Yes I am.
Clear as mud?
:) pretty much!! I have the settings for my applications stored in the MyApp.settings file. Would that be a bad idea? Also, when the settings are changed i.e. user has changed some stuff in the options window, the parent form doesn't autmatically apply the changes. For it to apply changes does it have to be "refreshed" or "reloaded"?
There's nothing wrong with using app.settings. For the app to take advantage of setting changes, you can have the host form get the settings from the options form before it is disposed, or read them from your app.settings file after the options form is closed.
private void ChangeSettings() {
MyOptionsForm mof = new MyOptionsForm();
// show your settings form as a dialog
// this line will show the form, and get the result when it closes
// but you still have the mof reference to it, and can access it's
// public properties.
if (mof.ShowDialog() == DialogResult.OK) {
// Make Setting Changes Here
// Expose setting properties from MyOptionsForm
// or re-read your settings file here.
}
}That help?
Try code model generation tools at BoneSoft.com.