Hola!

Estaba realizando un ejemplo con archivos y de este me  ha llevado a crear otro ejemplo con una barra de progreso.

En este caso conocemos el número de elementos que se van a añadir a una lista y que se representara
visualmente en el incremento de  la barra de progreso.

 

Su código:


Pregunta. ¿ Es de alguna manera el control ProgressBar un elemento decorativo ?.
A ver, si tu "no conoces" el número de elementos. Tendría que haber un proceso antes, que averiguase cuantos son los elementos
para usarlo como divisor. 1 / nelementos

Entonces.Si tu de alguna  manera vas incrementando el  divisor, puede que una vez que se ha terminado el proceso,
simplemente se represente de una manera "decorativa" el progreso de algo que ya se había hecho.

En este ejemplo en cambio es algo que esta sucediendo en el momento, si tu desconoces algo, no lo puedes a lo mejor representar
a la vez que esta ocurriendo el proceso, por eso digo lo de decorativo.

Saludos.

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Con respecto a que es decorativo.

Imaginar este caso. Voy a mostrar en la lista, un grupo de archivos que existen en un directorio.
A medida que los va añadiendo a la lista, el divisor aumenta.

¿ Que ocurre ?. Con un bucle antes he averiguado cuantos archivos hay, los he pasado a un array.
Y luego los muestro en la lista y aumento el valor de la barra de progreso.

Por un lado, tengo el proceso que cuenta los archivos y luego en el timer
los muestro y aumento el valor de la barra de progreso.

Entonces, no es algo, que esta ocurriendo.Se ha calculado el numero de archivos y se ha usado como divisor.



Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

"decorativo"

Puedes usar una imagen .gif (animación)

http://k09.kn3.net/135B7B562.gif

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

También puedes actualizar el número de elementos en cada tick del timer, mediante alguna rutina que se ejecute dentro del evento timer. No hay otra forma o al menos a mi no se me ocurre...

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Citar:

Pregunta. ¿ Es de alguna manera el control ProgressBar un elemento decorativo ?.
A ver, si tu "no conoces" el número de elementos. Tendría que haber un proceso antes, que averiguase cuantos son los elementos
para usarlo como divisor. 1 / nelementos

Pues sí, y no. No es algo que aporte nada a nuestro proceso, lo que lo hace decorativo, pero es algo que satisface al usuario que espera, lo que lo hace conveniente. De todas formas y, hablando de bases de datos, que es lo mío, no es necesario tener un proceso antes. Hay muchas rutinas sobre registros, por ejemplo o arrays, que ese primer proceso es consustancial al hecho, quiero decir que en ambos tengo la propiedad .count, que me es dada sin proceso previo más que el de recuperar los datos, claro. Y un progressbar sobre el proceso ni viene mal ni estorba.

Por otra parte... la pregunta es algo baladí (llevaba tiempo queriendo soltar el palabro, que me encanta, jejeje):
No se puede construir un itinerario si no se conoce el destino. Así como cualquier bucle en sí mismo lleva ya la meta. Por ejemplo:

La función Dir ya ha tenido que hacer ese proceso de recuperación y de almacenamiento de la meta, ergo ya hemos recorrido una vez el bucle (por decirlo así), y lo que hagamos nosotros siempre será una segunda vez.

Personalmente, y en principio, discrepo del uso de un timer con progressbar, me parece un fraude al usuario. Si estás haciendo un bucle de lo que sea, actualiza el progress en cada iteracción, el avance de la barra puede ser irregular... pero "honrado".
Saludos

[quote user="shordi" post="16807"]

Citar:

Personalmente, y en principio, discrepo del uso de un timer con progressbar, me parece un fraude al usuario. Si estás haciendo un bucle de lo que sea, actualiza el progress en cada iteracción, el avance de la barra puede ser irregular... pero "honrado".
Saludos

 De acuerdo con Shordi, debería irse actualizando en cada iteración y no por "tiempo". Yo la he usado más una vez con timer, pero justamente para mostrar cúanto tiempo queda para terminar algo (tiempo restante de juego, por ejemplo). También podrías usar un label e ir variando su propiedad text:
Van 12 archivos de 100 , van 13,van 14....hasta llegar al total.
Saludos  

===================
Migrando desde visual basic, el Gambas de Ms
Mi blog gambero

jguardon escribió: [Ver mensaje]

También puedes actualizar el número de elementos en cada tick del timer, mediante alguna rutina que se ejecute dentro del evento timer. No hay otra forma o al menos a mi no se me ocurre...

Cuando dije eso, al referirme el timer, por supuesto estaba pensando en cada iteración de un proceso, aunque me dejé llevar por el ejemplo que puso shell.

De hecho, así lo tengo hecho en una aplicación que importa registros de texto plano a una base de datos:



Donde pb.Value es el valor de la progressbar, n_char es un integer que acumula el número de caracteres leídos en cada iteración y file_l es la longitud del fichero en caracteres (~bytes), a partir de un Stat(fichero).size

La verdad es que para ese caso concreto funciona muy bien.

Saludos

===================
Jesús Guardón

Por favor, usemos el corrector ortográfico antes de pulsar el botón "Enviar".

"uo ǝs ʇɐu pıɟıɔıן ɐdɹǝupǝɹ ɐ dɹoƃɹɐɯɐɹ, soןo ɥɐʎ bnǝ dɹodouǝɹsǝןo"

Hola a todos.

Julio

Decorativo, en parte lo dije por que es algo visual que el usuario ve, pero que no tiene por que ser algo necesario para
la aplicación.En el caso de conteo y muestra de los archivos, hace algo mas que un barra que muestra un porcentaje
si mas. Pudiese ir a la par de la lectura de los archivos.

En cuanto a sustituir la barra por gráficos, acuérdate que lo hicimos (Lo de la esquinas no redondas).
Lo que no lo vi fue con un gif. No funciona el enlace, esta prohibido.  

Shordi

Bueno es aprender palabras nuevas.

Un bucle tiene un final definido, o un numero de iteraciones definidas.Aunque también los hay que no sabes
cuantas iteraciones o repeticiones puede tener, que dependen de una condición.

El uso del timer en el segundo ejemplo no era adecuado. Lo he intentado de otra manera sin timer y es mas razonable,
pero no acaba de funcionar del todo.

Dani

Con la barra de progreso quedara mas vistoso. Pero mejorando el segundo ejemplo, claro.

Jesús

Tengo que repasar bien tu solución.A ver si con un poco de tiempo lo veo mejor.


Gracias a todos.Cuando tenga un momento de lugar os muestro el ejemplo sin timer  que no era necesario en el segundo ejemplo
y a ver si logro que funcione.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Continuo con el ejemplo.Ayer no tuve tiempo para mostrarlo.

Lo mas simple que hice fue esto:



- Se crea un array con los nombres de los archivos.
- Se averigua el numero de archivos.
- Se averigua el valor del incremento, conocemos cuantos son.
- Por cada archivo en el array se hace:
--->Se añade a la lista cada uno de los archivos del array
--->Se aumenta el tamaño de la barra con el valor del incremento por cada archivo del array

Ok. Ahora el problema. Esta operación hace que ni la barra ni la lista se muestre hasta el final.
Entonces me veo, ¿ obligado ? a usar un retardo. Wait .Pero para usar wait prefiero un timer.
Por la razón de que wait a veces si se para por algún motivo la aplicación, crea problemas extraños.

Si se usa un timer, la rutina del Timer contendría:



Es que se cuantos archivos existen.Me lo da la función RDir.
Si fuera una base de datos, también puedo averiguar cuantos registros son.
No es algo, que no se sepa, el incremento es fijo.No hay variación.(Gracias a RDir, claro)




Saludos.

===================
Gambas Básico
"No es un bug, es una característica no documentada"

El uso del retardo es obligado para que la aplicación ejecute todas las operaciones pendientes, entre ellas el refresco de pantalla.
Si el progreso de la barra no es homogéneo(que en una rutina de mover cadenas a un array, como la que pones, no tiene por qué no serlo), es un reflejo de lo que está ocurriendo en el proceso, que puede ser útil para el interesado.

Imagina que la rutina es de copia de una lista de archivos a una carpeta:



La barra de progreso iría a trompicones según el tamaño del archivo que se copie en ese momento. Complementado con la etiqueta informativa (que le da tiempo a leer cuando se ralentice por archivos grandes) da al usuario una idea real de lo que está haciendo. El retardo de 0.01 es mejor para esto que el de 0.1... 10 veces más rápido, claro.
Saludos.