It's a good thing, in the long-run, to minimize the use of Global Variables, or Methods, or Functions, etc., in programming: it makes for cleaner code, and tighter control of possible unpredictable interactions in the code. Other complications may arise from use of global scope in multi-threading applications, or multi-user applications, or client-server applications, etc.
Some people have an almost "religious" conviction that any use of global variables is inherently bad, even "evil." In fact, the implementation of .NET itself uses global static enumerations, functions, and methods frequently. Every time you use a method like string.SubString(#,#) you are using a static method of the String Class. Every time you use something like myTextBox.BackColor = Color.AliceBlue; you are using the static Color Enumeration in System.Drawing.
For many people new to programming in C#, it is a little hard to get used to the idea that if you define a static method, function, or variable of some Type, in a Form, or UserControl, that what you have defined then becomes a method, function, or variable,
of the Form or UserControl. No matter how many instances of the Form, or UserControl, are created, there will be one, and only one, instance of the variable, method, or function.
The most common way to have a global variable in .NET C# is to define a Static Class in the same Namespace used by the other Classes that you wish to have access to the global variable.
See if you find this answer helpful: "How to define Global veriable in C#.net:" [
^].
I think the
danger, for a beginning programmer, in making use of global variables, is that it may
become a way to avoid the more rigorous discipline of learning how to pass data, or functions, or methods, from one object to another. And, carefully implementing the ways in which objects "talk" to each other is a key in programming for a future world where most applications are going to be multi-user, multi-threaded, client-server, etc.
So, when you say above that there's another class that should "know" about the changed value of a boolean variable in a second class: well, yes, you could create a static class that held a boolean that would be set by the second class anytime the boolean changed, and then the other class could always have access to the current value by using the static variable.
But, you could also implement that by passing a "message" from the second class to the other.
And, you could achieve that in several ways: via an Event; via exposing a public Property in the second class that the other class had access to, etc.
CodeProject's OriginalGriff (accept no imitation !) has written three excellent tutorials on how to implement message-passing in WinForms: from form to form; from form to "child" control; and, from "child" control to Form. I strongly suggest you study those: [
^].
The techniques in those three articles are easily adaptable to passing data between Classes that do not have a UI (i.e., are
not Forms, UserControls, etc.).