Global Variables

[Taggi]

Hallo! Me again!

Well, is in C# a posibility to define variables global?

For example is something like this possible?

class proggi
{
   public Connection;
   
   void run()
   {
      A.Init();
      B.Use();
   }
}
class A
{
   public void Init()
   {
      // Initialise Connection in class proggi
   }
}
class B
{
   public void Use()
   {
      // Use Connection in class proggi
   }
}

I know that it is easy, if I "put" the varibale Connection into the Parameter list of Init and Use. But is there a possibility to avoid this?

Thanks for help!

Taggi

[petes1234]

Hallo! Me again!

Well, is in C# a posibility to define variables global?

For example is something like this possible?

class proggi
{
   public Connection;
   
   void run()
   {
      A.Init();
      B.Use();
   }
}
.
.
.

Taggi

Making proggi public won't help?:

public class proggi
{
   .
   .
   .
}

[Taggi]

Hallo!

Sometimes I doubt in my brain...

Well...

Declaration:
public static Connection;

Use:
proggi.Connection = something;

I have tried without declaring the class proggi public and it Works too!

Thanks for Help.

Taggi

[Andy Tacker]

    public class proggi
    {
        static Connection m_Conn;
        public static Connection GetConnection()
        {
                return m_Conn;
        }
    }

[klintan]

In general, avoid global variables. It makes the code harder to maintain and test.

In C#, a field or property can be made global by making it static.

For ADO.Net connections, there is no need for a global variable. It is better to rely on connection pooling.

[dcell59]

It's OK to use global variables (we can use GOTO now, too :-)), but I think it's better to handle that kind of thing as a member of a class that has the lifetime you need. For example, in a web server, you already have several global variables available to use (such as Application) that you can add this kind of thing to. In a Windows Forms app, you have Program.

[TheCPUWizard]

public class proggi
    {
        static Connection m_Conn;
        public static Connection GetConnection()
        {
                return m_Conn;
        }
    }

ANDY A BigSlap to you.

Assuming this is some type of ADO or Communication conntection they should *always* be inside of a using statement.

[MadHatter]

public class proggi
    {
        static Connection m_Conn;
        public static Connection GetConnection()
        {
                return m_Conn;
        }
    }

ANDY A BigSlap to you.

Assuming this is some type of ADO or Communication conntection they should *always* be inside of a using statement.

I have a hard time reading a lot of your posts... absolutes are for idiots. if its in a using statement than by the time he gets it it will be disposed. using statements are a lazy mans way of closing out and disposing the object. I use using statements where they make sense, but you cannot wrap a complex DAL inside a single using statement (especially if you pool that connection across many places in your application).

[TheCPUWizard]

I have a hard time reading a lot of your posts... absolutes are for idiots. if its in a using statement than by the time he gets it it will be disposed. using statements are a lazy mans way of closing out and disposing the object. I use using statements where they make sense, but you cannot wrap a complex DAL inside a single using statement (especially if you pool that connection across many places in your application).

My apologies for being overly brief (not being sarcastic), my life is rather hectic right now, perhaps fewer and better posts would be a good idea.

"Absolutes are for Idiots". True, but some things are 99.999xxx% that it is easier to write it that way.

The idea is that you should NOT create an object whichimplements IDisposable, and then pass it out of the containing scope. FxCop will complain mightly on this one.

Both the Company I am working for, and my previous employer (a small company owned by Bill), have strong rules against this. If FxCop reports warnings on your code, you can not even check it into source control.

Try writing (and it can be done) some code that passes an IDisopsable object out of scope and guarentees 100% (not 99.995%) that the object will be disposed in All circcumstances (except a Rude Process Abort)....

Would you be willing to do this? (And agree to pay me $10 for every loophole I find that will avoid Dispose being called).

A bug in production could (and almost certainly would) cost more that $10.

[MadHatter]

writing frameworks, and writing business applications are often 2 very different beasts. business applications are much less likely to cause as much problems for as many people as something infragistics or microsoft writes. It wasn't until recently that ms started doing fxcop on their source code, because a lot of 1.0 and 1.1 code doesn't even pass all the rules.

[TheCPUWizard]

It wasn't until recently that ms started doing fxcop on their source code, because a lot of 1.0 and 1.1 code doesn't even pass all the rules.

100% Agreement, but the times they are a changing

And dont forget FxCop is 100% (well almost) customizable. If you decide to be stricter or looser on coding practices, I strongly recomment taking the time to customize FxCop (or another tool) rather than ignoring errors/warnings.

At 2am (where we have all been), it is easy for a human to make silly mistakes. An automated process will run just as reliabily at any time.

[Zaccheus]

The idea is that you should NOT create an object whichimplements IDisposable, and then pass it out of the containing scope. FxCop will complain mightly on this one.

Forms, Streams, many many classes implement IDisposable.

Why should I not pass these out of the containing scope?
Or rather, how can you write any meaningful application without doing so?

[TheCPUWizard]

Psuedo Code (its late )

  using (stream s = new stream)
  {
     dostuff with stream;
  }

need more power, use a delegate.

void SomeMethod(SomeDelegate d)
  using (stream s = new stream)
  {
     d(s);
  }

[MadHatter]

yes, always use a using statement to make cpuwizard happy. by all means, if you have a disposable object, dispose of it right after you create it, never dispose of an idisposable object yourself (leave that to the compiler to do) never dispose of your idisposable objects inside your dispose method, and always use the lazy using brackets (and go ahead and try to use automatic disposal on idisposable objects that dont support automatic disposal), never implement idisposable in your class that contains disposible objects, never use finializers, or any other conventions, just use disposable objects in the context of a using statement, and use objects in a using statement...

pretty solid logic.

[Zaccheus]

TheCPUWizard - how would you create forms which contain other controls?