Global variables in C#

[Guest]

Is it possible to create a 'global variable' in C# that can be used and
accessed between forms? I've used MODULES in Visual Basic, but can't find the
equivalent for C# ...

Thanks to all those responding,

 

[james]

Are you looking for static variables?

-James

 

[Guest]

Yes - variables that can be manipulated inside of any form that the user
touches during the application.

 

[Sam]

I don't think there is something equivalent in C#, you might want to use
static class which kinda does the same thing for you.

Sam

 

[Brian Gideon]

Is it possible to create a 'global variable' in C# that can be used and
accessed between forms? I've used MODULES in Visual Basic, but can't find the
equivalent for C# ...

Thanks to all those responding,

Just add a public static variable to any class.

 

[Guest]

Thanks Sam ...

Question: Would that be a PUBLIC statis class, so as to be available to all
forms?

Thanks,

 

[Sam]

Yes, its scope has to be public to be visible to all forms, and as well as
to others classes.

Sam

 

[Guest]

Thanks Brian ...

Just add a public static variable to any class.

 

[Guest]

Perfect ... thanks Sam ...

Yes, its scope has to be public to be visible to all forms, and as well as
to others classes.

Sam

 

[pedrito]

Actually, the class doesn't necessarily have to be static, though static
does fit into the picture at some point, I suppose.

By default, C# (and I use VS.NET 2003, so I'm still in the dark ages),
creates a windows form app with the app main() startup in the same file as
the initial form.

What I normally do is break this out into a separate class called MainApp or
something like this. I then create an instance of my MainApp and have a
public static MainApp.App field to get to the instance from any class.

Then I can store all sorts of global goodies in my MainApp and access it
from any class. I find this to be very handy for doing things having an
application preferences which can be loaded on startup and saved on
shutdown, and what have you.

 

[Brian Gideon]

Actually, the class doesn't necessarily have to be static, though static
does fit into the picture at some point, I suppose.

By default, C# (and I use VS.NET 2003, so I'm still in the dark ages),
creates a windows form app with the app main() startup in the same file as
the initial form.

What I normally do is break this out into a separate class called MainApp or
something like this. I then create an instance of my MainApp and have a
public static MainApp.App field to get to the instance from any class.

Then I can store all sorts of global goodies in my MainApp and access it
from any class. I find this to be very handy for doing things having an
application preferences which can be loaded on startup and saved on
shutdown, and what have you.

VS 2005 creates a Program.cs file by default that contains the entry
point and the call to Application.Run...very similar to what you're
doing manually right now.

 

[Jon Skeet [C# MVP]]

Actually, the class doesn't necessarily have to be static, though static
does fit into the picture at some point, I suppose.

By default, C# (and I use VS.NET 2003, so I'm still in the dark ages),
creates a windows form app with the app main() startup in the same file as
the initial form.

Fortunately this has changed in VS2005 - it creates Program.cs
separately from the main form. (It still creates Form1 by default,
which then doesn't get everything right when you rename it IIRC, so I
always delete Form1 and start again which is annoying... but never
mind!)

Jon

 

[Peter Duniho]

Fortunately this has changed in VS2005 - it creates Program.cs
separately from the main form. (It still creates Form1 by default,
which then doesn't get everything right when you rename it IIRC, so I
always delete Form1 and start again which is annoying... but never
mind!)

Can you recall the specific example of having problems renaming Form1?
I don't like "Form1" as a name (too generic), and always rename my
default for "real" applications (ie, not just thrown together for
testing). I don't recall having any trouble with this. I just change
the name in the class declaration, and VS updates it everywhere else for
me when I choose the appropriate refactor command. If I want to change
the actual source file name, it is similarly simple; just change the
name in the Solution Explorer, and it's done.

In fact, it's one of the things with which I've been impressed by
VS2005; it handles a wide variety of renaming scenarios in a practically
transparent manner, no matter how many different places need to be
touched to make things consistent.

I'd be curious what pitfalls await me, so that I'm not too surprised
when I finally run into them.

Pete

 

[Jon Skeet [C# MVP]]

Can you recall the specific example of having problems renaming Form1?
I don't like "Form1" as a name (too generic), and always rename my
default for "real" applications (ie, not just thrown together for
testing). I don't recall having any trouble with this. I just change
the name in the class declaration, and VS updates it everywhere else for
me when I choose the appropriate refactor command. If I want to change
the actual source file name, it is similarly simple; just change the
name in the Solution Explorer, and it's done.

I'll try it now.

In fact, it's one of the things with which I've been impressed by
VS2005; it handles a wide variety of renaming scenarios in a practically
transparent manner, no matter how many different places need to be
touched to make things consistent.

I'd be curious what pitfalls await me, so that I'm not too surprised
when I finally run into them.

Well, the first is that Form1.cs really *isn't* a nice source file
name. Surely it's quite rare that anyone *would* want a form really
called "Form1". If only VS asked you for the name of the main form, or
gave you an option to cancel... even "MainForm" would be better than
"Form1". (I know, I could change the templates - but it's a shame that
I have to.)

Given that I'd always want to rename the source file, in my test I did
exactly that to start with - and it gave me the option of renaming the
class as well. I accepted. Sure enough, the name was changed. The name
of the form (as on the designer) wasn't though.

Is this a huge blow? No... but it *is* about as much effort as deleting
the form and starting again, and more effort than if the project
started without the form at all.

If you refactor using the refactor menu, it doesn't (IIRC) offer to
change the name of the source file, so that has to be done separately.

As I say, asking the developer up-front would have been a much nicer
solution, IMO.

 

[Peter Duniho]

Well, the first is that Form1.cs really *isn't* a nice source file
name. Surely it's quite rare that anyone *would* want a form really
called "Form1". If only VS asked you for the name of the main form, or
gave you an option to cancel... even "MainForm" would be better than
"Form1". (I know, I could change the templates - but it's a shame that
I have to.)

No disagreement there. I think the initial default form should have the
same name as the project at a minimum, if VS isn't going to ask you for
a specific name.

But that's not really what I was asking about.

Given that I'd always want to rename the source file, in my test I did
exactly that to start with - and it gave me the option of renaming the
class as well. I accepted. Sure enough, the name was changed. The name
of the form (as on the designer) wasn't though.

You mean the Text property of the form instance?

Okay, I can see that as being an example of "doesn't get everything
right" in the sense that a brand new form would inherit the actual name.
On the other hand, I can't think of a single application I've written
in .NET where the Text property of the form was left being identical to
the in-code name of the form (ie, the default value assigned to it).

Or do you mean something else?

Is this a huge blow? No... but it *is* about as much effort as deleting
the form and starting again, and more effort than if the project
started without the form at all.

If you delete the only form in the project and then create a new one,
does the Main() method get updated properly so that the
Application.Run() statement instantiates your new form class instead of
the original one?

I have to admit, it never occurred to me to do this rather than just
renaming the form, and I agree that deleting and creating a new one is
slightly easier than renaming both the class and the .cs file
individually. But as you noted above, if you rename the file first, the
class can be renamed automatically. And if you still need to go back
and fix up the Main() method, I'm not sure that deleting the form and
starting a new one is easier.

If you refactor using the refactor menu, it doesn't (IIRC) offer to
change the name of the source file, so that has to be done separately.

Is this also the "doesn't get everything right" you were talking about?

If I understand it correctly, to sum up:

-- rename the .cs file, and the form instance's Text property isn't
updated

-- rename the class first, and you still need to rename the .cs
file, and the form instance's Text property isn't updated

As I say, asking the developer up-front would have been a much nicer
solution, IMO.

I agree. Just wanted to make sure I wasn't overlooking some subtle "hey
this didn't get changed" bug in code where I've renamed my form classes
and .cs files.

Thanks,
Pete

 

[Jon Skeet [C# MVP]]

No disagreement there. I think the initial default form should have the
same name as the project at a minimum, if VS isn't going to ask you for
a specific name.

But that's not really what I was asking about.
Sure.


You mean the Text property of the form instance?

Okay, I can see that as being an example of "doesn't get everything
right" in the sense that a brand new form would inherit the actual name.
On the other hand, I can't think of a single application I've written
in .NET where the Text property of the form was left being identical to
the in-code name of the form (ie, the default value assigned to it).

Or do you mean something else?

No, that's what I mean - and I do see what you mean too. It's very rare
that you'd use an actual type name for the form's title.

If you delete the only form in the project and then create a new one,
does the Main() method get updated properly so that the
Application.Run() statement instantiates your new form class instead of
the original one?

No, you would indeed need to do that manually.

I have to admit, it never occurred to me to do this rather than just
renaming the form, and I agree that deleting and creating a new one is
slightly easier than renaming both the class and the .cs file
individually. But as you noted above, if you rename the file first, the
class can be renamed automatically. And if you still need to go back
and fix up the Main() method, I'm not sure that deleting the form and
starting a new one is easier.

I suspect it's about the same, to be honest.

Is this also the "doesn't get everything right" you were talking about?

No, although it counts in a different tally

If I understand it correctly, to sum up:

-- rename the .cs file, and the form instance's Text property isn't
updated

-- rename the class first, and you still need to rename the .cs
file, and the form instance's Text property isn't updated

Yup. I don't know of anything more than that. In 2003 it was worse, of
course, due to the lack of refactoring support.

I agree. Just wanted to make sure I wasn't overlooking some subtle "hey
this didn't get changed" bug in code where I've renamed my form classes
and .cs files.

I don't think so

 

[pedrito]

Jon Skeet [C# MVP] wrote: [snip]

Given that I'd always want to rename the source file, in my test I did
exactly that to start with - and it gave me the option of renaming the
class as well. I accepted. Sure enough, the name was changed. The name of
the form (as on the designer) wasn't though.

You mean the Text property of the form instance?

I suspect either that or the Name property (or both) is what he means.

Okay, I can see that as being an example of "doesn't get everything right"
in the sense that a brand new form would inherit the actual name. On the
other hand, I can't think of a single application I've written in .NET
where the Text property of the form was left being identical to the
in-code name of the form (ie, the default value assigned to it).

Or do you mean something else?


If you delete the only form in the project and then create a new one, does
the Main() method get updated properly so that the Application.Run()
statement instantiates your new form class instead of the original one?

[snip]

No doubt it gets updated properly and that's a problem as well.

I do almost exactly what Jon does, but I'm doing it from 2003. My method of
doing it, in the actual mechanics of things, is to rename Form1.cs to
MainApp.cs and delete all the form code leaving only the main() and renaming
the class to MainApp.

Then I create my "first form" and whatever I'm calling it is what I put in
the Application.Run().

Personally, I think if VS.NET isn't going to ask you what to name the first
form, you'd be better off without it for this exact reason. I suppose you
could create a custom wizard to do it. Frankly, if someone would, it would
probably be worth a little money. All you'd have to do is give the option to
set the name of the first form and do everything else the same way VS.NET
does it. It'd definitely save me a few minutes for nearly every app I write
which adds up.

I don't know what new refactoring facilities VS.NET has, but I do know there
are some pretty good plugins for VS.NET that will do pretty comprehensive
refactoring.

I use visual assist which I find to be money well spent, especially coming
from the VS.NET 2003 point of view, as it has a lot of the facilities that
2005 finally got.

 

[Adam One]

you can use application domain, like;
System.AppDomain.CurrentDomain.SetData("strVar_1", "The Value One")

in your first form or entry point, and if you need the strVar_1 anywhere in
your forms or classes you can call like ;

AppDomain.CurrentDomain.GetData("strVar_1")

.....



Adam

 

[Enkidu]

Fortunately this has changed in VS2005 - it creates Program.cs
separately from the main form. (It still creates Form1 by default,
which then doesn't get everything right when you rename it IIRC, so I
always delete Form1 and start again which is annoying... but never
mind!)

This is only aesthetic, though. No end user is going to see the name of
the form, are they?

Cheers,

Cliff

 

[Jon Skeet [C# MVP]]

This is only aesthetic, though. No end user is going to see the name of
the form, are they?

They're not going to see the names of my variables, either - but that
doesn't mean I call everything int1, int2, int3, int4 etc.

Names are an important part of code readability - and "Form1" tells me
*nothing* about what the form is for.