static controls

[Nadav]

Hi
I have a control on my form, and in the code I decided to define it static.
every change i make to the design of the form, this control is back to being
non-static, and i have to change the code over and over to make it static
again.
is there a solution to this ?
Nadav

[Marc Gravell]

Re: static controls

I'm not sure that it makes much sense for either a Control (class) to be
declared static, nor for a Control (instance) on a form to be in a static
field (on the form).

In the former, you couldn't ever create an instance to place on any form; in
the latter, you have *no* thread safety (think affinity), *no* proper
control ownership (think TopLevelControl , disposal etc)...

In a very controlled situation, this /might/ be reasonable, but I can't
think of any...

Have I misunderstood your question? If so, could you post a short
illustration of what you are trying to do?

If this is, for instance, to share information between forms, then perhaps a
standalone class that the forms make use of (and get notifications from via
events) is a better model.

Marc

[Ignacio Machin \( .NET/ C# MVP \)]

Re: static controls

Hi,

First you have to ask yourself why this control is static??
static controls are a pain , remember that a control is contained in a form,
it has a parent and is in dependand of this to receive events.

IF for some weird need you have no choise but make it static, then you
cannot use the designer for it, the designer can change at will the code it
use to declare/initialize the controls



--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation


"Nadav" <nadav3@gmail.c om> wrote in message
news:ul$MZxUaGH A.5088@TK2MSFTN GP03.phx.gbl...[color=blue]
> Hi
> I have a control on my form, and in the code I decided to define it
> static.
> every change i make to the design of the form, this control is back to
> being non-static, and i have to change the code over and over to make it
> static again.
> is there a solution to this ?
> Nadav
>[/color]

[Joanna Carter [TeamB]]

Re: static controls

"Nadav" <nadav3@gmail.c om> a écrit dans le message de news:
ul$MZxUaGHA.508 8@TK2MSFTNGP03. phx.gbl...

| I have a control on my form, and in the code I decided to define it
static.
| every change i make to the design of the form, this control is back to
being
| non-static, and i have to change the code over and over to make it static
| again.
| is there a solution to this ?

Yes, don't define it as static !!

Why would you want a control as static ? This means that you will only ever
have one instance of the control for all instances of the form. Every change
you make to such a control's properties would be reflected in all instances
of the form.

I would guess that you are editing the section of form code that is
commented as designer generated and should not be changed.

If you are using VS2005, you can add your control to the non-designer part
of the partial class and should not have the same problems.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Nadav]

Re: static controls

Hi, thanks for the reply..
I did it static because I had to change it from another class.
Maybe you can tell me how I can get to the controls on the main form from
code of another class and not of the main form itself ?

thanks.

"Marc Gravell" <marc.gravell@g mail.com> wrote in message
news:%23R6q33Ua GHA.4144@TK2MSF TNGP04.phx.gbl. ..[color=blue]
> I'm not sure that it makes much sense for either a Control (class) to be
> declared static, nor for a Control (instance) on a form to be in a static
> field (on the form).
>
> In the former, you couldn't ever create an instance to place on any form;
> in the latter, you have *no* thread safety (think affinity), *no* proper
> control ownership (think TopLevelControl , disposal etc)...
>
> In a very controlled situation, this /might/ be reasonable, but I can't
> think of any...
>
> Have I misunderstood your question? If so, could you post a short
> illustration of what you are trying to do?
>
> If this is, for instance, to share information between forms, then perhaps
> a standalone class that the forms make use of (and get notifications from
> via events) is a better model.
>
> Marc
>[/color]

[Marc Gravell]

Re: static controls

Well, there is no such thing as "the main form" - it's just your app that
invents this.
Possible solutions:
* Pass a reference to the main form to each child form (can get messy when
lots of forms involved)
* If there genuinely is only ever one of these "main" forms, then you could
place it's reference into a static property of the main form; any other code
can then access it
* If the child forms are effectively notifying the main form of changes,
then use events
* If the child forms are reading data, then bind to data classes (i.e. each
form only knows about the *data*; it doesn't know about the UI on any other
form)
* About 20 other models...

Personally, I hate strongly coupling forms together; it makes it a pain to
re-use or refactor, painful to change the UI flow, and can lead to threading
issues etc. I recomment the use of events and separate data classes

If you have something specific, small and demonstrable, then post it - but
not reams and reams of stuff - just the essence.

Marc

[Bruce Wood]

Re: static controls

I'm assuming that you want only one of your "main form" to exist at any
time, that you never want two of them.

If so, just make it a singleton:

public class MainForm : Form
{
private static MainForm _instance = null;

private MainForm()
{
... the usual constructor stuff ... note that it's "private"
....
}

public static MainForm Instance
{
get
{
if (MainForm._inst ance == null)
{
MainForm._insta nce = new MainForm();
}
return MainForm._insta nce;
}
}
}

Now whenever you want to get at your main form, just say:

MainForm.Instan ce

and you will get the (only) main form.

On top of this, it's very bad style to go directly into your form an
look at / monkey with controls on the form. It's far better to expose
properties and methods that allow other forms to ask for and do
specific things. For example, if you wanted to know what customer name
the user entered on the main form, this would be nasty:

string name = MainForm.Instan ce.customerText Box.Text;

Yuck. This is much nicer:

string name = MainForm.Instan ce.CustomerName ;

where CustomerName is a field on your main form:

public string CustomerName
{
get { return this.customerTe xtBox.Text; }
}

This accomplishes two things: 1) it gives you more control; perhaps you
want other forms to be able to see the customer name but not change it;
2) it allows you to later change the control for the customer name from
a text box to, say, a combo box, or a list view, and outside forms
don't need to know what happened.