Estoy haciendo un control heredado de la clase GridView, al cual quiero incorporar el enlace a las tablas de mysql. Todo guay y perfecto, pero no consigo que se levante el evento Data... ¿Alguien puede orientarme?
Ese evento no es un método del control, sino que tú lo colocas en el código del formulario con el nombre micontrol_Data(row,column) y se dispara cuando es necesario... pero ¿quién lo dispara y quién decide cuándo es necesario?

El control que he estoy haciendo lo creo en tiempo de ejecución al llamar al formulario que lo contiene (en el evento _new del formulario)
Algo así  como:


Después de esto debería dispararse el evento Data pero ni flores... creo que tengo algo mal comprendido respecto a la oops...



No sé si me explico...

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

Me auto-corrijo:
Aunque no tengo ni pajolera idea de C, he estado mirando el código fuente del GridView y _Data sí es un evento que levanta el propio GridView. Ahora bien, sigo sin entenderlo: El código del evento Data del GridView está dentro de la clase del  Formulario, pero es levantado por el GridView... No entiendo nada.

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

shordi escribió: [Ver mensaje]

... pero no consigo que se levante el evento Data... ¿Alguien puede orientarme?
Ese evento no es un método del control, sino que tú lo colocas en el código del formulario con el nombre micontrol_Data(row,column) y se dispara cuando es necesario... pero ¿quién lo dispara y quién decide cuándo es necesario?

Como bien dices, ese evento se dispara cuando es necesario, es decir, cada vez que una celda se hace visible.

Por ejemplo, si tienes una tabla con 10000 registros, lógicamente no entran todos en la superficie visible de tu gridview, incluso habrá columnas que no se vean. Pues bien, cada vez que una celda necesita ser mostrada, por ejemplo al hacer scroll para ver el resto de registros, se dispara el evento _Data().
No es el scroll en sí mismo, sino la propia visibilidad de las celdas con datos lo que lanza el evento.

El evento va estrechamente ligado al objeto Result que usas para adquirir los datos de tu tabla y es necesario incluir hresult.MoveTo(Row) dentro del manejador de evento para que cada vez que sea necesario mostrar una fila, el puntero interno del objeto result se mueva (y devuelva) los resultados.

De manera que:



Ten en cuenta que el método manejador del evento _Data se debe declarar como público. Si es private nunca se dispara.
Otra cosa a tener en cuenta es la disponibilidad de la conexión. Si se cierra la conexión mientras "navegas" por los resultados en el grid, tendrás un error. Te lo digo porque a mí me costó semanas depurar ese mismo error, y era que por otro lado estaba cerrando la conexión a la bd, dando como resultado un objeto Result nulo. Es decir, deberás mantener las conexiones abiertas al menos hasta que cierres el formulario que contenga el gridview (o hasta que tú lo consideres, según la lógica de tu programa). Si estás haciendo un control heredado, deberás tener esto muy en cuenta para prever posibles errores.

Para mí, esta es la mejor forma de trabajar con gridview, sobre todo si se manejan muchos, muchísimos registros, porque la mejora en velocidad es espectacular. Piensa que solamente se consultan y se dibujan las celdas visibles.

Espero que sirva de ayuda, 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"

Bueno, me parece que no queda mucho por decir del tòpico en cuestión. Sólo quiero responder a esto:

Citar:

para Fabianfv Y Demás Expertos En Oops

lol. ¡Al fin alguien se dio cuenta que soy un experto en Oops (pronunciado: "ups")!

¡Oops! Es lo que suelo decir muchas veces por día, cada vez que cometo un error

O como diría Homero Simpson: ¡Ouch!

Ahora si tu alusión es a la programación orientada a objetos :),  considero que un experto en POO es alguien como Alan Kay o Bertrand Meyer. Yo, sólo soy un aprendiz (que en algún momento le ha tocado calzarse el traje de maestro).

Por otra parte hay alguien en este foro que nunca quiere reconocer explícitamente que la tiene bastante más clara que todos nosotros y ese es nuestro querido amigo y administrador del foro: Jesús Guardón, que en muchos sentidos es el alma y el corazón de esta comunidad. Por supuesto son varios los integrantes de la comunidad cuyos aportes son destacables y a quienes no quiero desmerecer. Pero, para que quede claro que hablo con fundamentos sólo basta considerar la importancia de sus aportes, entre los que puedo mencionar:

• Las características incluidas en los foros de este sitio web hacen que sea uno de los mejores foros existentes sobre un lenguaje de programación.
  
• Su aporte brindando a la comunidad paquetes de la última versión de gambas mientras ello fue útil.
  
• Sus scripts de descarga e instralación de la última versión de gambas 2 y 3 desde los fuentes, que nos permite a muchos de nosotros la posibilidad de contar siempre con la última versión con una facilidad increíble.
  
• Las aplicaciones que ha desarrollado, alguna más importante y otras más pequeñas pero siempre mostrando muy buenos criterios tanto de programación como de diseño de interfaces gráficas.
  
• Sus aportes en los distintos foros, siempre acertados - Round(99,99)-
  

En algún momento habrá que darle un mejor uso al canal IRC y empezar con alguna charla formativa y creo que jguardon debería dar el puntapié inicial.

Bueno, pasé por aquí en un día muy ajetreado para mí, lo que demuestra que me estoy haciendo gambas dependiente, pero uno de estos días me tomaré algo más de tiempo para exponer un control sobre el que estuve trabajando.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Jesús:
Efectivamente el evento data acelera ad infinitum el gridview, el problema es en el momento en que haces el control heredado...
Para empezar, ¿qué nombre das al evento, el de la instancia del control heredado + _Data?  y ¿dónde lo sitúas? ¡En el propio control o en el formulario?
Dudas que me llevan de cráneo... lo que no he comprobado es si el result es el mismo todo el tiempo o lo recreo en algún momento. Lo compruebo y te cuento. Gracias por las pistas, de todas formas.

Fabian:
Coincido contigo en lo que a Jesús se refiere 100 %. De todas formas no te quites méritos, que tus respuestas me han ayudado en muchas ocasiones y son siempre un referente.... y hablando de foreros magníficos: ¿qué fue de Soplo?, mira que se le echa de menos...

Suerte

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

Hola Shordi. Hace bastante poco, he hecho una clase que me controla la grabación, borrado, actualización con su barra de navegación propia, bloqueo de controles fuera de la edición y todo eso. He declarado eventos para antes y después de mover result a otro registro, antes y después de grabar, de borrar y de actualizar.
Los eventos no había manera de que funcionaran y probando y probando vi que necesita un observador en el formulario que instanciaba a la clase. De modo que me pregunto yo... no te hará falta que cuando instancies ese gridview lo hagas con un observer? Si no hay observer no se detecta ningún evento.

PUBLIC migrid AS gridv

PUBLIC SUB Form_Open()

   migrid = NEW gridv as "migrid"

...
...

END

PUBLIC SUB migrid_Data(Row as Integer, Column AS integer)

   $resultDatos.MoveTo(Row)

...
...

END

Espero haber sido de ayuda.
Un saludo

Antonio


END

El mensaje de antonio me dio la pauta sobre cual puede ser el problema, también he releido el mensaje de Shordi  pero no estoy seguro de interpretar correctamente el problema. De todos modos si de algo sirve, ahí va.

Hay un problema con respecto a las clases de formulario cuando se usan para crear un control y es que no hay forma de declarar un evento y que efectivamente el usuario del control pueda capturarlo. Por ello resulta necesario crear una clase independiente que sirva como interfaz con el usuario del control.

Hay 2 formas de lanzar un evento desde la clase de un formulario y que pueda ser 'relanzado desde una clase consumidora:

• El evento declarado en el formulario es capturado por un observer en la clase que actúa como interfaz (el observer lo relanza automáticamente, por lo que ya debería ser capturable desde el código que use el control).
  
• La clase consumidora define un método oculto que debe llamarse desde el formulario en reemplazo del lanzamiento del evento. El método oculto lanza el evento definido en la clase interfaz.
  

El problema es claro, gran parte de la interfaz de la clase que realmente se quiere escribir debe repetirse entre la clase interfaz y la clase del formulario, mientras que si la clase del formulario realmente pudiera usarse como una clase "normal", esto no tendría por que ser así. Benoit me dijo hace un tiempo que la forma de escribir controles en gambas necesitaba re-hacerse desde cero, no se si es para tanto pero este problema me parece que merece una solución en Gambas3.

Bueno, estoy apurado en este momento así que si no me he explicado claramente, por favor me lo dicen y trato de explicarlo mejor.

===================
Cómo programar con Gambas

Speed Books: informática libre.

He abierto un hilo nuevo con lo que estoy intentando hacer. A ver si así queda más clarito. Ejj que no sé ni por dónde tirar, oiga.

Por cierto Fabian, se me olvidaba, siempre digo las siglas americanas OOP u OOPS, que castellanizadas (POO) tienen algo de escatológico...

Suerte

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