shordi escribió:  

Por otra parte, no veo la relación de usar máquinas poco potentes con la versión de gambas que uses... gambas no tiene requerimientos especiales de capacidad, tan sólo que las librerías necesarias para la ejecución del programa existan en las máquinas. Ni siquiera necesita que existan las librerías que se necesitan para la ejecución del propio Gambas.

los daruma soportan fulctuaciones, de electricidad, soportan golpes de los empleados que me salen baratos, soportan golpes y polvo..
me saldria muy costoso viajar a cada ciudad cada 2 semanas solo para limpiar polvo en cada maquina.. prefiero una poderosa maquina que lo aguante todo.. el ahorro en costes es muchisimo.. puesto la maquina es hermetica... y extremo barata...
un i7 con el polvo se daña al tiempo.. los daruma tienen mas de 10 anios conmigo, en guindows no serviand pero con mi idea ...una maravilla.. que que estoy explotando.. falsas acusaciones....cuanta calumnia

Citar:

Aliviaría mucho a esas máquinas si les desinstalas el gambas entero que llevan y sólo instalas los programas compilados que necesites.

asi estan...

Citar:

Me dijiste que lo hacen es trabajar con el IDE y que los programas los pasas en forma de librerías (ejecutables) que los usuarios copian y pegan dentro de los programas. Eso es un poco desastre como sistema de trabajo. Es más lento de ejecutar, consume más memoria,

me explique mal.. el punto de venta, no ve ni siente nada, sino me robarian.. asi que como no voy mandar el tecnico, el mismo gerente copia y pega su archivo que arranca... si mete la pata el mismo programa reporta...

Citar:

y más costoso para las máquinas que tienen que correr el IDE además de el programa, sin hablar de la posibilidad de error humano, la pérdida o duplicidad de versiones y la siempre posible modificación accidental del código que queda expuesto.

en el equipo no corre el ide, solo esta el runtime y algunos modulos...

shordi escribió:  

Lo de la no existencia propiedad selection de la clase rows en tu versión de gambas, ni idea. Así es como funcionan los GridViews ahora y no me voy a poner a programar para versiones obsoletas. Si esa propiedad no existía en la versión 3.5, pues elimina el código que la menciona y adáptalo a lo que necesites.
La referencia de la línea 99 sólo sirve para dar color a las líneas seleccionadas, para las otras puedes eliminar la propiedad Selection del wGrid por completo...

EXCELENTE! gracias! trabajando... yo mismo hago el codigo apra que se adapte, hay una variable que pregunta en tiempo de ejecucion por la version...
con todo esto voy hacer un repositorio de git con todo esto, porque aqui aun andan con svn y no se ve los cambios...

Citar:

El wordWrap no tiene nada que ver con el ancho de las columna. Sólo con el alto. Son dos cosas distintas.

WordWrap lo que hace es adaptar el alto de la línea para que quepa todo el contenido del campo. Si es false, sólo aparecerá el que quepa en el ancho de la columna.

ya ya me confundi.. tambien lo queria modificar.. ya se donde.. excelnte info.. trabajando...

Citar:

El ancho lo controlas con la propiedad widths  que es un integer[] en la que puedes poner un ancho fijo, -1 para un ancho estándar y -2 para un ancho adaptativo por cada columna.

exclente, trabajando

Citar:

Esta propiedad está relaciona con otra expandcols de tipo bóolean. El comportamiento es:

Si especificas el ancho de una columna en la propiedad widths, ese ancho se respeta siempre y es fijo.
Si no especificas ancho para una columna y expandcols es true, esa columna se adaptará al ancho disponible en el grid (cambiaran el ancho si cambias el tamaño del wGrid)
Si no especificas ancho para una columna y expandcols es false, esa columna tomará un ancho automático, normalmente basado en el título.

Un ejemplo:

Código: [Descargar] [Ocultar] [Seleccionar]

Código: [Descargar] [Mostrar]

miGrid.rows.count=5 'cinco columnas
miGrid.expandcols=true
miGrid.widths=[100,50]  

Las dos primeras columnas serán de 100 y 50 de ancho respectivamente y el resto se adaptará al ancho del grid

Código: [Descargar] [Ocultar] [Seleccionar]

Código: [Descargar] [Mostrar]

miGrid.widths=[100,50,-2,-1,-1]

Las dos primeras serán fijas, la tercera se adaptará y las dos últimas tendrán un ancho automático.
Si no estableces ningún valor para widths, entonces, todas las columnas se adaptarán o todas serán estándar según el valor de expandcols.

En widths puedes poner tantos valores como columnas haya o menos. Si una columna adaptable, se modifica su ancho en tiempo de ejecución (pinchando entre dos cabeceras y arrastrando), pasa a ser una columna fija y dejará de adaptarse.

Citar:

Así escrito parece muy complejo, pero no lo es. A lo mejor tendría que hacer un vídeo sobre el manejo de estas clases...

Saludos

QUEREMOS VIDEO! QUEREMOS VIDEO! QUEREMOS VIDEO!  

hola shordi encontre otros detalles y los ajuste.. despues los posteo..

sin embargo uno importate que no veo como resolverlo aun..

cuando doy click para ordenar, todo va bien, pero en algunas ocasiones (ya lo probe y ocurre en el codigo original) los nombres de columnas se pierden!

dado cuando coro por pasos no veo cuando desaparece los nombres de las columnas y se pone el de la primera fila , forzando las columnas no lo resuelve, porque el bug ocurre despues de haber asignado los nombres de columnas

alguna sugerencia? please!

El uso de la primera fila como cabecera de columna se controla con la propiedad setheads.

Cuando setheads es cierta, como cabeceras de columnas:
-Si Source es un result, se usa el nombre de los campos.
-Si source es un array de colecciónes, se usan las claves de la primera colección
-Si source es un Variant[][], se usan los valores del primer array.
-Si es falsa no se ponen más cabeceras que las que tú establezcas en la propiedad Titles.

Si por algún motivo la cambias a medio proceso, el comportamiento cambiará. Fuera de eso no puedo decirte nada porque a mí me funciona perfectamente. Al haber modificado tú el código, no puedo decirte más: A mí me funciona.

Saludos

===================
No podemos regresar

shordi escribió:  

Si por algún motivo la cambias a medio proceso, el comportamiento cambiará. Fuera de eso no puedo decirte nada porque a mí me funciona perfectamente. Al haber modificado tú el código, no puedo decirte más: A mí me funciona.

Saludos

estoy probando el codigo "virgen" es decir sin alterar, y cuando busco varias veces se pierden las cabeceras y se ponen los valores de una de las fils al azar...

no encuentro el porque

hay otros bugs, como que si ordenas y no hay datos explota o que ordena datos vacios.. esos ya se donde corregirlos.. tambien el de que desaparece el input de busqueda cuando cambias de orientacion la barra de busqueda...

esto ocurre cuando llenas con mas de 30mil registros... estoy usando sqlite..

Pásame un proyecto que produzca el error y le echo un vistazo, pero es difícil corregir bugs que no puedes duplicar...

===================
No podemos regresar

shordi escribió:  

Pásame un proyecto que produzca el error y le echo un vistazo, pero es difícil corregir bugs que no puedes duplicar...

te lo envie por correo, aqui no subio por el tamaño, la foto con el error, mira las columnas arriba

pasos:
abre, ejecuta, aparece.. escribe en el filtro,
importante, ahora ve al final y al inicio
filtra la primera, importante ahora vueklve ir al final y al inicio..
escribe otro filtro filtra la segunda
otra vez recorre con el raton la ventana hasta el final y al inicio
liiimpia los filtros..
aqui desaparecen las columnas.-.

los otros bugs no los mande corregidos para que no digas que fue la alteracion

 

Corregido. Lo tienes en la granja y aquí: https://foro.gambas-es.org/viewtopic.php?f=5&t=6450

===================
No podemos regresar

shordi escribió:  

Corregido. Lo tienes en la granja y aquí: https://foro.gambas-es.org/viewtopic.php?f=5&t=6450

no no ! nada de eso, por eso es que no me gusta ni la granja ni subidas, explicame! ilustrame!

quiero saber donde estaba!, con este ultimo detalle empiezo estudiar el que hiciste para odbc!

wGrid tiene tres posibles fuentes de datos: un Result, un array de colecciones y un array de string[]. La propiedad source, en su método source_write lo que hace es convertir todo al tercer tipo: Un array de arrays string[]. Si la propiedad setheads es True utiliza como cabeceras de columna

-El nombre de los campos, si es un result (linea 287 del wgrid en la versión anterior)
-Las claves de la primera colección si es una colección (linea 323 de la version anterior
-Los valores del primer string[]  si es un Array[][] (como ocurre cuando le pasas el resultado de un CSV, por ejemplo, que suelen llevar el nombre de los campos en la primera fila) (linea 343 de la verision anterior)

Por otro lado, cuando estableces un filtro se hace una copia del array[][] construido por la propiedad source_write. y cuando pulsas el botón de deshacer filtros se envia esa copia (llamada $original) en el código, como source de wGrid.
El fallo es que antes la primera vez se usaban los nombres de campo porque source era un result y al pulsar "Quitar Filtro" lo que se usa como source es un Varian[][], y entonces se usaba (porque $setheads sigue true) la primera fila del array.
Lo he modificado para que en lugar de meter directamente los nombres de campo o de claves de la collection[] en las cabeceras, las meta en la propiedad $titles y sea éste $titles el que se usa de cabeceras siempre.(líneas 352 a 354 de wGrid)

Si tienes alguna duda, pregunta.

Saludos

===================
No podemos regresar