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.

[Peter Duniho]

On Sat, 21 Jun 2008 09:27:23 -0700, kirk <ki****@gmail.comwrote:

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.

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

[KS]

"kirk" <ki****@gmail.comskrev i meddelelsen
news:bf**********************************@x1g2000p rh.googlegroups.com...

>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]

On Jun 21, 10:12*am, "Peter Duniho" <[e-mail]>
wrote:

On Sat, 21 Jun 2008 09:27:23 -0700, kirk <[e-mail]:

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.

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
}

[Peter Duniho]

On Sat, 21 Jun 2008 11:07:27 -0700, kirk <ki****@gmail.comwrote:

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.

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

[kirk]

On Jun 21, 4:24*pm, "Peter Duniho" <[e-mail]>
wrote:

On Sat, 21 Jun 2008 11:07:27 -0700, kirk <[e-mail]:

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.

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.

[Peter Duniho]

On Sat, 21 Jun 2008 17:30:14 -0700, kirk <ki****@gmail.comwrote:

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

[kirk]

On Jun 21, 5:39*pm, "Peter Duniho" <[e-mail]>
wrote:

On Sat, 21 Jun 2008 17:30:14 -0700, kirk <[e-mail]:

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!

[Peter Duniho]

On Sat, 21 Jun 2008 19:09:19 -0700, kirk <ki****@gmail.comwrote:

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'm not sure. You wrote later something about "1.1 compliance effort".
Are you trying to get your types into the Settings class in a 1.1
application? If so, maybe there is indeed some version issue. Otherwise,
I'm reasonable confident that you should be able to get it to work. I
haven't done it myself, but very reliable people have told me it would.

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!

You're welcome. I think your proposed solution should work just as well
as getting the Designer's Settings class to work. In fact, some times it
makes more sense to just stick with what's already working. :)

Pete

[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.ApplicationSettingsBa se
{
[global::System.Configuration.UserScopedSettingAttr ibute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttr ibute()]
public MyClass MySetting {
get {
return (MyClass)this["MySetting"];
}
set {
this["MySetting"] = value;
}
}
}
}

Chris Jobson