Properly sharing data between forms

[kirk]

I have program.cs, my "main" form and then a "settings" form.

My "main" form existed for awhile and I had constants, instantiations,
properties, etc within it created.

I went to create my "settings" form and constantly found myself
adjusting my "main" form entities to be static and inevitably just
passing in the "main" forms 'this' instance to the "settings"
constructor to simplify it all.

My question is, what is the proper way to be setting this all up. Is
there a way to avoid all of this, and give all forms implicit access
to this written common code in the "main" form? I have many forms to
come later and I don't want to have to tailor each to have a property
or constructor to accept one or more form instances holding
information they may need.

 

[KS]

I have program.cs, my "main" form and then a "settings" form.

My "main" form existed for awhile and I had constants, instantiations,
properties, etc within it created.

I went to create my "settings" form and constantly found myself
adjusting my "main" form entities to be static and inevitably just
passing in the "main" forms 'this' instance to the "settings"
constructor to simplify it all.

My question is, what is the proper way to be setting this all up. Is
there a way to avoid all of this, and give all forms implicit access
to this written common code in the "main" form? I have many forms to
come later and I don't want to have to tailor each to have a property
or constructor to accept one or more form instances holding
information they may need.

If I understand you right.

Just make an object instance with all you setting values and "store" it in
Properties.Settings.Default.

If you want to use some of the "global" settings in another form - just
declare a new object and populate it with the settings from
Properties.Settings.Default.

This way you can "implement" the VB-like global variables.

Best regards
KSor, Denmark

 

[kirk]

I'm not sure I understand the question.  For "settings" that aren't  
actually specific to a form, they shouldn't be in a form in the first  
place.  Most likely, they'd be found in the project's Settings class, but  
if not then at least some other static class that would be exposed to any 
other code in the project.  For "settings" that are specific to a form  
instance, then obviously you would naturally have to pass a reference to  
an instance of that form to control the settings for that instance.

Can you provide an example where you've got a setting that is not specific  
to an instance of a form, but you feel that a correct design is to pass an  
instance of a form anyway?

Pete- Hide quoted text -

- Show quoted text -

Below is short mockup of what I am running into today. I an
envisioned an architectural change of putting all of the common code
in the main program.cs file, instantiating all of the forms from
program.cs(currently it only starts MainForm), and all of those forms
would have access to common code to play with and share.

MainForm
{
// onload pulls data from registry to work with locally only
// instantiates a network class to watch for network disconnect/
connect
// event handler to network class to watch for disconnect/connect
// method here to sync local registry data back to registry as
needed

// button here to instantiate SettingsForm
}


SettingsForm
{
// contains controls to be populated based on pulled down registry
data in MainForm
// onload gets preserved data from MainForm local registry data
// clicking "ok"/"apply" updates MainForm local registry data
// clicking "ok"/"apply" calls MainForm method to sync local
registry data back to registry

}

FutureForm
{
// will run concurrent with MainForm later
// subscribe to same event handler to network class in MainForm
// do individual work pertinent to FutureForm on network disconnect/
connect
// call method in MainForm to sync local registry data
}

 

[kirk]

There's nothing about the "short mockup" you posted that explains why  
"MainForm" is managing the "data from registry".

In a .NET application, the kinds of things that normally would have been  
stored in the registry are instead maintained using the Designer-provided 
"Settings" class.  But whether you use the registry or Settings, there's  
nothing that would normally compel you to put the management of that data 
in a particular form.

It seems to me that you need a shared class, probably static but maybe  
singleton instead, where the settings are stored.  Normally, this would 
just be the "Settings" class, but if you really want to use the registry, 
you could write a similar class yourself that uses the registry instead of  
the normal .NET settings management techniques.  Either way, all of that  
code would exist outside of any of the forms.  The form classes would  
access the settings through the settings class, rather than maintain the  
settings themselves.

Pete

Thank you for the details on the "Settings" class. Pretty fancy. I
have tried to keep my app .NET 1.1 compliant, hence my old-school
approach on using the registry for data preservation. I'm curious,
could that class also store and globalize unique types that i've
developed and use the services of the types(methods, event sinks,
etc)?

There was no reason in particular that MainForm is serving as a
centralized point for everything, i.e. registry management, object
instances to tap into. This is my first Forms-based application, and
I lack intelligence in the Forms world.

It sounds like all of the back pedaling i'm doing, making what is in
MainForm, static to give it global visibility to the other forms is
really what you are suggesting as one option. Just move it over to a
separate shared class.

 

[kirk]

Thank you for the details on the "Settings" class.  Pretty fancy.  I
have tried to keep my app .NET 1.1 compliant, hence my old-school
approach on using the registry for data preservation.  I'm curious,
could that class also store and globalize unique types that i've
developed and use the services of the types(methods, event sinks,
etc)?

It should.  I admit that my experience doing that is non-existent, but my  
understanding is that any type that is serializable can be included in the  
Settings class, including your own.  You would need to make those types 
serializable, of course.  

[...]
It sounds like all of the back pedaling i'm doing, making what is in
MainForm, static to give it global visibility to the other forms is
really what you are suggesting as one option.  Just move it over to a
separate shared class.

If I've understood the question correctly, yes.  I agree.

Pete

Hmmm.

I tried making a custom type serializable and it does not show up in
the list of "types" in the Settings dialog, so i'm guess that means
unsupported?

I think i'm going to stick with my 1.1 compliance effort, dump all the
common code to a static shared class and call this a wrap. Thank you
for the help and your patience!

 

[Chris Jobson]

I tried making a custom type serializable and it does not show up in

the list of "types" in the Settings dialog, so i'm guess that means
unsupported?

I had this problem too, but as the Settings class is a partial class I just
extended it by adding another file with code similar to the following:

namespace MyProgram.Properties {
internal sealed partial class Settings :
global::System.Configuration.ApplicationSettingsBase
{
[global::System.Configuration.UserScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
public MyClass MySetting {
get {
return (MyClass)this["MySetting"];
}
set {
this["MySetting"] = value;
}
}
}
}

Chris Jobson