static fields in class scope

J

Jon Slaughter

I have some static fields in a class to keep track of "global" information
but this information is local to each form that the class is used on.

e.g., the class represents a base control(inherited from
System.Windows.Forms.Control) but keeps static information for all the
controls on the form (such as a global control style property). The problem
I just realized is that if I want to have multiple forms then I'm screwed if
the static fields are global to all controls created even though they might
be on different forms(so it would change the style of all controls that
exist even on different forms). This might not be so bad for a "global"
style but I also have other information that can be different on different
forms(but common to all controls on that form).

So is the method of using static fields impossible for this?

The reason I have this is so that I can easily change the global styles
instead of having to loop through all the controls on the form but it seems
like this might be my only choice?

Any ideas about this?

Thanks,
Jon
 
M

Michael C

Jon Slaughter said:
I have some static fields in a class to keep track of "global" information
but this information is local to each form that the class is used on.

e.g., the class represents a base control(inherited from
System.Windows.Forms.Control) but keeps static information for all the
controls on the form (such as a global control style property). The
problem I just realized is that if I want to have multiple forms then I'm
screwed if the static fields are global to all controls created even
though they might be on different forms(so it would change the style of
all controls that exist even on different forms). This might not be so bad
for a "global" style but I also have other information that can be
different on different forms(but common to all controls on that form).

So is the method of using static fields impossible for this?

The reason I have this is so that I can easily change the global styles
instead of having to loop through all the controls on the form but it
seems like this might be my only choice?

Any ideas about this?

Just remove the static keyword and then it becomes an instance variable.

Michael
 
J

Jon Slaughter

Michael C said:
Just remove the static keyword and then it becomes an instance variable.

yeah, but then the "global" aspect of it is completely anhilated in one fail
swoop.
 
J

Jon Shemitz

Jon said:
yeah, but then the "global" aspect of it is completely anhilated in one fail
swoop.

Not if multiple controls point to the same style object. Then,
changing a style object changes all controls that refer to it
(presumably you have some sort of StyleChanged event) but not the ones
that refer to other style objects.
 
J

Jon Slaughter

Cor Ligthert said:
Jon,

Why not create a form for you own by inheriting the base?

You mean put the field in the form? I guess that will work. These controls
were not ment to be constrained within a specific form class but I guess I
could do that since I think I'm heading along those lines anyways.

I guess its equivilent though. Its more convinent in my case to do it like I
want but that might be impossible.

It would be nice if one could "associate" static members with object
instances. In essence it does what you say but behind the scenes.

Maybe something like

Form F = new Form();

F.Attach(Control_Class);

Where essentially what Attach would do is put the static variables(or one
might need a special keyword) in the F instance.

then maybe later one could do

Form G = new Form()
G.Attach(Control_Class);

and the "special static" variables would actually use a new set of
variables.

I guess this method isn't that great as it would either require updating the
whole class or using double indirect pointers(which I guess isn't that
hard).

What is equivilent though is that the compiler will duplicate the class so
we might have something like

class Control_Class
{
static data;
}

and the compiler will generate

class Control_ClassX1
{
static data;
}

and update all the references with G to refer to Control_ClassX1 instead of
ControlClass

I guess this causes more problems than its worth though.

I suppose in the end your idea is much easier to do and get the job done
instead of thinking about other possibilities that will probably never work
or be implemented anyways ;/

Thanks,
Jon
 
D

Dave Sexton

Hi Jon,

You can use a dictionary keyed by the Form in your control (2.0 framework
example):

private static readonly Dictionary<Form, ControlSettings> settings = new
Dictionary<Form, ControlSettings>();

public static ControlSettings GetSettings(Form form)
{
if (!settings.ContainsKey(form))
settings[form] = new ControlSettings();

return settings[form];
}

I suggest that you encapsulate the settings into a class as well, just like
in the example above. You can access settings for the current Form by
creating a property:

class AppFormBase : Form
{
public ControlSettings Settings
{
get
{
return YourControl.GetSettings(this);
}
}
}

Instead of copying the above method to all of your Forms you could derive
the Forms in your application from AppFormBase. That way you only need the
following code, for example:

void SomeMethodInDerivedForm()
{
// assign the BackColor for the calling Form only
BackColor = Settings.BackColor;
}
 
M

Michael C

Jon Slaughter said:
yeah, but then the "global" aspect of it is completely anhilated in one
fail swoop.

That's what you wanted!! To have each instance of the form have it's own
style.

Michael
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top