C# - Winforms - Variables globales

Question

Quiero que algunas variables sean globales en todo el proyecto y accesibles en todas sus formas. ¿Cómo puedo hacer esto?

Answer 1

sí se puede mediante el uso de la clase estática. así:

static class Global 
{ 
    private static string _globalVar = ""; 

    public static string GlobalVar 
    { 
     get { return _globalVar; } 
     set { _globalVar = value; } 
    } 
} 

y para usar en cualquier lugar se puede escribir:

GlobalClass.GlobalVar = "any string value" 

Answer 2

O usted podría poner sus variables globales en el app.config

Answer 3

public static class MyGlobals 
{ 
    public static string Global1 = "Hello"; 
    public static string Global2 = "World"; 
} 

public class Foo 
{ 

    private void Method1() 
    { 
     string example = MyGlobals.Global1; 
     //etc 
    } 
} 

Answer 4

Puede utilizar static class o Singleton pattern.

Answer 5

Una forma,

Explorador de soluciones> Su proyecto> Propiedades> Settings.Settings. Haga clic en este archivo y agregue definir su configuración desde el IDE.

acceder a ellos por

Properties.Settings.Default.MySetting = "hello world"; 

Answer 6

Si está utilizando Visual C#, todo lo que necesita hacer es agregar una clase que hereda de Program.cs Forma y cambiar toda la clase heredada de forma a su clase en todos Formulario * .cs

//Program.cs 
public class Forms : Form 
{ 
    //Declare your global valuables here. 
} 

//Form1.cs 
public partial class Form1 : Forms //Change from Form to Forms 
{ 
    //... 
} 

Por supuesto, puede haber una manera de extending the class Form without modifying it. Si ese es el caso, ¡todo lo que necesita hacer es extenderlo! Dado que todos los formularios lo están heredando de forma predeterminada, ¡todos los objetos de valor declarados se convertirán en globales automáticamente! ¡¡¡Buena suerte!!!

Answer 7

Ya han respondido cómo usar una variable global.

Le diré por qué el uso de variables globales es una mala idea como resultado de este question llevado a cabo en stackoverflow en español.

traducción explícita del texto en español:

Impacto del cambio

El problema con las variables globales es que crean dependencias ocultas. Cuando se trata de aplicaciones grandes, usted mismo no sabe/recuerda/tiene claros los objetos que tiene y sus relaciones.

Por lo tanto, no puede tener una noción clara de cuántos objetos está utilizando su variable global. Y si quiere cambiar algo de la variable global, por ejemplo, ¿el significado de cada uno de sus valores posibles, o su tipo? ¿Cuántas clases o unidades de compilación cambiará? Si la cantidad es pequeña, puede valer la pena realizar el cambio. Si el impacto será grande, puede valer la pena buscar otra solución.

¿Pero cuál es el impacto? Debido a que una variable global se puede usar en cualquier parte del código, puede ser muy difícil medirla.

Además, siempre trate de tener una variable con el menor tiempo de vida posible, de modo que la cantidad de código que hace uso de esa variable sea la mínima posible, y así comprenda mejor su propósito, y quién lo modifique.

Una variable global dura por la duración del programa, y ​​por lo tanto, cualquiera puede usar la variable, ya sea para leerla, o incluso peor, para cambiar su valor, lo que hace más difícil saber qué valor tendrá la variable en cualquier punto del programa dado. .

orden de destrucción

Otro problema es el orden de destrucción. Las variables siempre se destruyen en el orden inverso de su creación, ya sean variables locales o globales/estáticas (una excepción son los tipos primitivos, int, enum s, etc., que nunca se destruyen si son globales/estáticos hasta que finalizan programa).

El problema es que es difícil conocer el orden de construcción de las variables globales (o estáticas). En principio, es indeterminado.

Si todas las variables globales/estáticos están en una única unidad de compilación (es decir, sólo tiene un .cpp), entonces el orden de construcción es la misma que la de la escritura (es decir, las variables definidas antes, se construyen antes de).

Pero si tiene más de un .cpp cada uno con sus propias variables globales/estáticas, el orden de construcción global es indeterminado. Por supuesto, el orden en cada unidad de compilación (cada .cpp), en particular, se respeta: si la variable global A se define antes B, A se construirá antes B, pero es posible que entre A y B variables de otra .cpp son inicializado Por ejemplo, si tiene tres unidades con las siguientes variables globales/estáticas:

Image1

En el ejecutable que se puede crear en este orden (o en cualquier otro orden, siempre y cuando el orden relativo es respetado dentro de cada .cpp):

Image2

¿Por qué es esto importante? Porque si hay relaciones entre diferentes objetos globales estáticos, por ejemplo, que algunos utilizan otros en sus destructores, quizás, en el destructor de una variable global, utilice otro objeto global de otra unidad de compilación que resulte ya destruida (tenga construido más tarde).

dependencias ocultos y * casos de prueba *

He intentado encontrar la fuente que voy a utilizar en este ejemplo, pero yo no lo encuentro (de todos modos, que era para ejemplificar el uso de embarazos únicos, aunque el ejemplo es aplicable a variables globales y estáticas). Las dependencias ocultas también crean nuevos problemas relacionados con el control del comportamiento de un objeto, si depende del estado de una variable global.

Imagine que tiene un sistema de pago y desea probarlo para ver cómo funciona, ya que necesita hacer cambios, y el código es de otra persona (o la suya, pero desde hace algunos años). Abre un nuevo main y llama a la función correspondiente de su objeto global que proporciona un servicio de pago bancario con una tarjeta, y resulta que ingresa sus datos y le cobran. ¿Cómo, en una prueba simple, utilicé una versión de producción? ¿Cómo puedo hacer una simple prueba de pago?

Después de preguntarle a otros compañeros de trabajo, resulta que debe marcar "verdadero", un bool global que indica si estamos en modo de prueba o no, antes de comenzar el proceso de recopilación. Su objeto que proporciona el servicio de pago depende de otro objeto que proporciona el modo de pago, y esa dependencia se produce de forma invisible para el programador.

En otras palabras, las variables globales (o singletones) hacen imposible pasar al "modo de prueba", ya que las variables globales no pueden reemplazarse por instancias de "prueba" (a menos que modifique el código donde se crea dicho código) o definido). variable global, pero suponemos que las pruebas se realizan sin modificar el código madre).

Solución

Esto se resuelve por medio de lo que se llama * inyección de dependencia *, que consiste en hacer pasar como un parámetro de todas las dependencias que un objeto necesita en su constructor o en el método correspondiente. De esta forma, el programador ** ve ** lo que le debe suceder, ya que tiene que escribirlo en código, lo que hace que los desarrolladores ganen mucho tiempo.

Si hay demasiados objetos globales, y hay demasiados parámetros en las funciones que los necesitan, siempre puede agrupar sus "objetos globales" en una clase, estilo * fábrica *, que crea y devuelve la instancia de el "objeto global" (simulado) que desea, pasando la fábrica como parámetro a los objetos que necesitan el objeto global como dependencia.

Si pasa al modo de prueba, siempre puede crear una fábrica de pruebas (que devuelve diferentes versiones de los mismos objetos) y pasarla como un parámetro sin tener que modificar la clase de destino.

¿Pero siempre es malo?

No necesariamente, puede haber buenos usos para variables globales. Por ejemplo, valores constantes (el valor de PI). Siendo un valor constante, no hay riesgo de no conocer su valor en un punto dado del programa por cualquier tipo de modificación de otro módulo. Además, los valores constantes tienden a ser primitivos y es poco probable que cambien su definición.

En este caso, es más conveniente utilizar variables globales para evitar tener que pasar las variables como parámetros, simplificando las firmas de las funciones.

Otro puede ser servicios "globales" no intrusivos, como una clase de registro (guardando lo que sucede en un archivo, que generalmente es opcional y configurable en un programa, y ​​por lo tanto no afecta el comportamiento nuclear de la aplicación), o std :: cout, std :: cin o std :: cerr, que también son objetos globales.

Cualquier otra cosa, aunque su tiempo de vida coincida casi con el del programa, siempre páselo como parámetro. Incluso la variable podría ser global en un módulo, solo que sin ningún otro acceso, pero que, en cualquier caso, las dependencias siempre están presentes como parámetros.

respuesta por: Peregring-lk

Answer 8

El consenso aquí es poner las variables globales en una clase estática como miembros estáticos. Cuando crea una nueva aplicación de Windows Forms, generalmente viene con una clase Program (Program.cs), que es una clase estática y sirve como el punto de entrada principal de la aplicación. Vive durante toda la vida de la aplicación, por lo que creo que es mejor colocar las variables globales en lugar de crear una nueva.

static class Program 
{ 
    public static string globalString = "This is a global string."; 

    /// <summary> 
    /// The main entry point for the application. 
    /// </summary> 
    [STAThread] 
    static void Main() 
    { 
     Application.EnableVisualStyles(); 
     Application.SetCompatibleTextRenderingDefault(false); 
     Application.Run(new Form1()); 
    } 
} 

y utilizarlo como tal:

public partial class Form1 : Form 
{ 
    public Form1() 
    { 
     Program.globalString = "Accessible in Form1."; 

     InitializeComponent(); 
    } 
}