https://foro.gambas-es.org/viewtopic.php?f=4&t=861&p=4854#p4854
-----------------------------------
fabianfv
Miercoles, 11 Agosto 2010, 00:23

Re: Mas Sobre GridView Heredado Y Su Evento Data
-----------------------------------
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:

[code linenumbers=false syntax=gambas]
PRIVATE  $hObserver AS Observer

...

PUBLIC PROCEDURE _New()
  $hObserver = NEW Observer(ME) AS "myGridView"
  ....
END

PUBLIC PROCEDURE myGridView_Data(Row AS Integer, Column AS Integer)
  ME.rellenar(Row, Column)
END
[/code]

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

[list]
[*]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.
[/list]
Un consejo Shordi, refactoriza antes de seguir, es decir, intenta hacer lo siguiente.

[list]
[*]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.
[/list]

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 :)


