Comunidad Gambas-es

Esto es lo que intento hacer:

Un gridview que contenga en sí mismo todo lo necesario para la visualización de la base de datos, a saber: una conexión, una sentencia sql, un orden, y un Result, de forma que no necesite ser alimentado en cada formulario y que pueda ser manejada como objeto.

Para ello tengo esta nueva clase que llamo, por ejemplo, "migrid"




Luego creamos un formulario y le asignamos el siguiente código:


Con esto teóricamente debería crearse el gridview, que se crea, con las columnas, que se crean, y sus datos que NO se crean por falta de evento Data...

¿Alguna idea? Me lleva loco el tema....

Suerte

Shordi, creo que ya te lo habían dicho, pero no sé si lo probaste: para capturar el evento deberías crear un objeto observer en el constructor (_new)

Creo que algo así debería funcionar:



De todos modos creo que deberías ordenar un poco el código y seguir fielmente algunas pautas de POO:

• Tu código no respeta el principio de encapsulamiento. Deberías cambiar las variables públicas por propiedades.
  
• Veo que usas algunas abreviaturas para nombrar las variables. Si quieres que alguien más que tú mismo entienda tu código sin problemas, no deberías usar abreviaturas.
  
• Aunque no lo analicé detenidamente me parece que posiblemente tu clase "migrid" no respete el principio de responsabilidad única (viene a ser lo mismo que con las funciones: deben hacer una única cosa). Deberías tener en cuenta que tu proyecto es un control que puede componerse de varias clases, no necesarimente de una sola. Encontrar cuáles deberían ser esas clases debe ser el primer paso.
  
• Hay métodos que me parece no deberían ser públicos: esos también estarían rompiendo el encapsulamiento.
  

Un consejo Shordi, refactoriza antes de seguir, es decir, intenta hacer lo siguiente.

• Crea un nuevo proyecto.
  
• Escribe primero la interfaz de la clase (propiedades y nombres y argumentos de los métodos que los usuarios de tu control deberían ver) sin su implementación. Así podrás definir cómo quieres que tu control sea usado, sin preocuparte de cómo lo implementarás.
  
• Crea un módulo para probar la clase (si ya sé que aún no hace nada, por eso es el momento justo para empezar a probarla). En ese módulo deberás empezar a escribir procedimientos que creen un objeto, establezcan sus propiedades y prueben sus métodos, siempre comparando si los resultados son iguales que los valores esperados.
  
• Define las variables y métodos que usará internamente la clase (que deben ser privados), sin su implementación.
  
• Analiza un poco el diseño de la/s clase/s, para ver si la interfaz que definiste es adecuada o si le faltan métodos públicos o propiedades.
  
• Implementa primero las propiedades y métodos públicos en términos de variables y métodos privados. Es decir, si observas que un método público necesita, por ejemplo, calcular la longitud de una vaca adulta, pon una llamada a un método "PRIVATE FUNCTION getLongAdultCow() AS Float" que implementarás después (la primera implementación de "getLongAdultCow" debería ser algo como Return 2,07 para permitir que puedas ejecutar las pruebas de entrada nomás).
  
• Del punto anterior puede surgir evidencia de que necesitas variables o métodos privados adicionales: defíne su interfaz pero no su implementación.
  
• Cada vez que implementas un método o propiedad, escribe en un módulo algunas pruebas que podrían hacer fallar ese método o propiedad. Ejecuta el módulo de pruebas y corrige las fallas que vayan surgiendo.
  
• Completa la implementación de cada método, ejecutando las pruebas luego de cada modificación importante para asegurarte que no introduces nuevos fallos.
  

Un proceso así es lo que generalmente se recomienda para lograr un buen diseño y una buena modularización. Es el proceso lo que ayuda a disminuir la cantidad de errores que uno comete; se mejora la comprensión sobre qué se debe hacer en cada momento al definir primero las interfaces y al escribir pruebas y ejecutarlas cada vez que se introducen modificaciones importantes.

Si quieres seguir mi consejo y necesitas ayuda para hacerlo no dudes en avisarme, en el proceso yo aprenderé mucho

¿Ves como sí eres el interlocutor adecuado? jeje.
Mil gracias.
Efectivamente, ese código no es más que un primer intento de convertir un puñado de funciones que tenía agrupadas en un módulo, y que portaba de aplicación en aplicación prácticamente intactas, en un objeto. Tiempo empleado en el análisis: 13 segundos (más o menos).
No podía emplearme más sin saber si era posible hacerlo (nunca he heredado un control gráfico) y ahí me estrellé.

Por otra parte no sabía que se podía declarar un observador vía código, que eso lo dijo Jesús y no me enteré de la copla, me temo.
Una respuesta orientadora como la tuya es lo que esperaba y te estoy super agradecido. Dame unos días para que le dé vueltas al tema y subiré lo que vaya consiguiendo, código o problemas. Posiblemente más de lo segundo que de lo primero... jejeje

Gracias otra vez. Este es el mejo foro del mundo mundial.

Suerte


Edito: otografía, ortografía...

Hola Shordi, creo que en el hilo en que empezaste esta consulta, ya te dije lo que me paso a mi. La clase creada por mi no era gráfica pero lo de los observer debe de ser igual.
Por defecto un objeto es su propio observador. Yo uso los observer cuando quiero interceptar el funcionamiento de algunos controles (no todos) y responder a ciertos eventos de la misma forma para ese grupo.
Como todos queremos ahorrarnos código escrito, te vuelvo a decir que lo que haría sería, al instanciar tu grid personalizado declararlo con su propio observador.

DIM arrtable AS String[5]
DIM elGrid AS miGrid

elGrid = NEW miGrid AS "observaMiGrid"

'Debería funcionar ahora en este Form desde el que instancias, el evento Data

PUBLIC SUB observaMiGrid_Data(Row AS Integer, Column AS Integer)

'un array con los nombre de los campos aquí pon los tuyos y sácalo de aquí y ponlo en Form_Open()
arrtable[0]="cod"
arrtable[1]="fecha"
arrtable[2]="concepto"
arrtable[3]="cantidad"
arrtable[4]="origen"

ResultDeDatos.MoveTo(Row)
TVultGastos.data.Text = Str(ResultDeDatos[arrtable[Column]])

END

Perdón por volver con lo mismo pero creo que lo fácil es mejor, no se

Antonio

Disculpa ahtonio, atribuí más arriba tu respuestas en el otro hilo a Jesús.
En el otro como que no lo entendí. Ahora, juntando todas vuestras ayudas, como que lo entiendo.
Me pongo a probarlo (sin prisas, que es agosto...) y cuando tenga algo que contar ipsofactamente os lo comunico.
Gracias a todos.

Suerte

Hola Shordi, como te comente en privado, intento adjuntarte el fuente por si quieres probarlo y/o verlo.

Recibido. Ya te cuento... y mil gracias.