progressBar_barrra_progreso.Value = 0; // Resetear progressBar a 0.
Lo correcto, tanto por estética del código fuente, como por rendimiento y seguridad del producto final, sería utilizar el método
ProgressBar.Increment:
progressBar1.Increment(1);
De esta forma evitarías futuros posibles errores humanos como sería por ejemplo:
progressBar1.Maximum = 100;
progressBar1.Value = 101;
...Este código de arriba provocaría una excepción de tipo
ArgumentOutOfRangeException, mientras que si usases el método
ProgressBar.Increment podrías rebasar el valor máximo por accidente sin provocar ninguna excepción.
Ejemplo demostrativo:
progressBar1.Maximum = 100;
for (int x = 0; x <= 999; x++) {
progressBar1.Increment(1);
}
No sé si habrás tenido la oportunidad de leer lo que programadores profesionales siempre han opinado sobre el método
Application.DoEvents, pero todas las opiniones escritas en la World Wide Web se podrian resumir brevemente en las siguientes palabras: "
Application.DoEvents() is EVIL, do not use it." - y quien dijo eso tuvo mucha razón. No debes utilizar dicho método a menos que seas consciente de lo que hace y como lo hace intérnamente, sé que es una via de escape facil para solventar la respuesta o responsiveness de la interfáz de usuario, pero es que esa metodología conlleva muchas desventajas, y a día de hoy es prehistórica. Lo único que te debería importar es lo siguiente: al lo único que consigues llamando a ese método de forma continua dentro de un búcle, es disminuir el rendimiento (la velocidad) de tu programa y el algoritmo de copiado, y no lo estás disminuyendo un poco, sino MUCHO ( puedes hacer la prueba por ti mismo con y sin llamar a
Application.DoEvents() ).
( Aquí te dejo una opinión del gran gurú
Hans Passant:
https://stackoverflow.com/a/5183623/1248295 )
En lugar de utilizar el método
Application.DoEvents(), puedes utilizar esto otro método:
...De esta manera, las llamadas continuas a
Application.DoEvents() se disminuirán en consideración, y con ello aumentará bastante el rendimiento de tus algoritmos donde tengas que llamar a
Application.DoEvents(). Y por supuesto al usar esta alternativa/mejora, la interfáz de usuario seguirá siendo responsiva a los eventos de notificación de Click.
...Pero mucho mejor y más correcto que utilizar
Application.DoEvents(), que como ya dije ES UNA METODOLOGÍA PREHISTÓRICA (aparte de peligrosa), sería recurrir a los instrumentos que .NET Framework nos proporciona hoy en día, me refiero a la programación asincrónica, ni más, ni menos. Si necesitamos interactuar con los elementos de control de una UI, entonces lo más adecuado sería utilizar el componente
BackgroundWorker, puesto que está precisamente diseñado para llevar a cabo la interactuactuación con la UI, pero podemos utilizar la classe Task, o Thread. También es importante utilizar los métodos
Control.BeginInvoke /
Control.Invoke según las circunstancias. Hay varias maneras de llevarlo a cabo, depende del escenario / circunstancias.
Por último, te muestro un pequeño ejemplo gráfico:
PD: Ahora que lo pienso mejor, debería haber escrito "responive UI" en lugar de "app" en la imagen, pero bueh. Si, ya sé que me preocupo por tonterías, soy así de exquisito o perfeccionista... según se mire xD.
Saludos.
Autor
En línea
