Comunidad Gambas-es

Shordi:
ok, voy a intentar reemplazar el panel con un formulario, pero no recuerdo donde, pero una vez lei que el observador de eventos del formulario "padre" no ve tampoco los eventos del formulario "hijo". Lo cual me lleva a que no puedo reutilizar el código si es así ya que panel o formulario-incrustado da lo mismo a la hora de ver los eventos.
Pero no lo probé, luego comento que tal fue.
Y tranqui que yo suscribo a la filosofía "keep it simple stupid" todo lo que me permite mi nivel técnico

Gracias y Saludos.

+1

Bueno, probé usar un formulario incrustado dentro de otro, pero el formulario padre NO ve los eventos del formulario hijo lo cual me lleva otra vez al casillero de partida.
Es una lastima porque abriría muchas posibilidades, con menos código que escribir.
Saludos.

Eso es fácil de solucionar, creo. Dame un rato y te subo un ejemplo.

Saludos.

shordi escribió: [Ver mensaje]

Eso es fácil de solucionar, creo. Dame un rato y te subo un ejemplo.

ok. gracias.

Aquí tienes un ejemplo de un formulario que muestra los campos de una tabla y cuyos eventos puedes controlar desde el formulario principal (en este caso sólo muestra una lista de registros y el detalle al hacer click sobre uno de ellos.
Verás que tienes tres sitios desde donde puedes controlar los eventos de los controles (hablamos siempre del evento Action),

- en el propio formulario: en el evento click de los botones del formulario "hijo" (si es que quieres darles un comportamiento estándar)
- en el evento Action_Activate del formulario "hijo"
- en el evento Action_Activate levantado por el "hijo" y observado en el formulario "padre".

El programa incorpora una base de datos sqlite que saqué de no sé dónde y ahí podras comprobar cómo se le asigna a cada control creado la propiedad Action (se establece al nombre del control que, a su vez, se establece al nombre del campo). Unos controles levantan el evento Action_Activate como los botones y los checkboxes y otros no, como los textbox y como te ocurría a tí con el buttonbox.

El truco, como verás esta en extender la clase Detalle con un evento más: Action_Activate, que es levantado (Raise) dentro del evento interno Action_Activate del Formulario. (Puede ser lioso el haber elegido el mismo nombre para el nuevo evento, pero es mucho más claro y nemotécnico su funcionamiento).
En el formulario padre estableces un observador mediante la cláusula AS y a partir de ahí puede controlar todos los eventos del formulario en el formulario padre.
Este es el aspecto:


El código de creación de los controles lo he sacado del programa siesta, simplificándolo un poco y es bastante tosco pero creo que como ejemplo es válido para asumir cómo funciona la técnica.

Espero que te sirva.

Saludos

Gracias Shordi. lo he descargado y me pondré a analizarlo.

Shordi:
He probado el código que subiste, luego de analizarlo hoy (ayer no pude) creo que entendí como funciona, pero el eldetalle_Action_Activate solo levanta los eventos del click del CheckBox pero si hago click en un TextBox o si le cambio el contenido no hace nada.
¿Es una limitación del método o hay que crear eldetalle_Action_Change? Que por cierto lo he hecho y no funciono.
Lo que me interesa es levantar los eventos (change, click, Dblclik, GotFocus, LostFocus, etc. ) de los controles creados en el interior.
Ademas de poder saber como se llama el control para actuar dependiendo de que nombre tenga el control.

Saludos.

tincho escribió: [Ver mensaje]

Shordi:
He probado el código que subiste, luego de analizarlo hoy (ayer no pude) creo que entendí como funciona, pero el eldetalle_Action_Activate solo levanta los eventos del click del CheckBox

Y de los botones, que controlan la acción real del formulario

Citar:

pero si hago click en un TextBox o si le cambio el contenido no hace nada.

Sí hace, le da el foco y almacena en su propiedad text los cambios, es decir hace lo que debe hacer un textBox.

Citar:

Lo que me interesa es levantar los eventos (change, click, Dblclik, GotFocus, LostFocus, etc. ) de los controles creados en el interior.

Esto último es contradictorio, no puedes usar un conjunto de controles creados por código (es decir de los que no sabes ni su nombre ni su tipo etc, pues dependen de una base de datos o de lo que sea) para luego programar comportamientos específicos de los eventos de esos controles. Quiero decir: si en tiempo de diseño sabes lo que quieres que haga un control específico y quieres programarle un comportamiento... créalo en tiempo de diseño. Si no lo sabes, no puedes.
No veo qué te ahorras en la creación de un control por código si luego tienes que ir creando código para cada control.

Citar:

Ademas de poder saber como se llama el control para actuar dependiendo de que nombre tenga el control.

La respuesta es la misma: Si necesitas codificar basándote en el nombre del control, crea el control en tiempo de diseño.

El ejemplo que te dí observa el evento Action_Activate de todos los controles que así lo hagan, es decir: Controla todas las acciones que "hace" un formulario. Los controles button, checkbutton, etc. Puedes incluir en el formulario de detalle comportamientos estándar (grabar, cancelar, añadir) o puedes hacerlo en el fMain, incluyendo (ahora sí) funciones de validación de los campos, etc. pero repito, Si tienes que crear un control que conlleve una programación específica, créalo en tiempo de diseño del formulario

Otro tema es la automatización de procesos repetitivos estándar (crear los controles a partir de un result, rellenar un formulario desde un result, vaciar un formulario de los datos que muestre, dar altas, bajas y modificaciones, etc. etc.) Eso se puede hacer de manera simple con funciones dentro de un módulo y olvidarte de ello, pero siempre estamos hablando de comportamientos estándar.

Saludos

shordi escribió: [Ver mensaje]

...Esto último es contradictorio, no puedes usar un conjunto de controles creados por código (es decir de los que no sabes ni su nombre ni su tipo etc, pues dependen de una base de datos o de lo que sea) para luego programar comportamientos específicos de los eventos de esos controles. Quiero decir: si en tiempo de diseño sabes lo que quieres que haga un control específico y quieres programarle un comportamiento... créalo en tiempo de diseño. Si no lo sabes, no puedes.
No veo qué te ahorras en la creación de un control por código si luego tienes que ir creando código para cada control.

Seria contradictorio si las características del control las "decide" solamente la base de datos, como en el caso de siesta, pero yo lo plantee de otra manera, creo el control sabiendo que es lo que va a hacer este y sabiendo además como se va a llamar exactamente, mediante una lógica de análisis que tiene en cuenta un "mapeo" previo de la base de datos, donde por ejemplo defino los títulos de los campos para diversos "escenarios" o informes, entre otras cosas.
Como se exactamente como se llama el control, y de donde provienen los datos en el caso que sean desde un resultado o desde settings o desde un archivo de texto. Esto me permite establecer una lógica relativamente sencilla de que hacer cuando se produce un evento especifico en cada uno de estos controles.
El planteo es que el campo es una "propiedad" del control y no al revés.
Es mas, las bases con las que estoy trabajando son todas de texto, no hay ni date, bolean, integer, float, nada, solo texto. el único integer es el indice de la tabla. Entonces para recuperar y escribir una fecha uso una función a tal efecto, y lo mismo para un float o un integer, pero todo se guarda como texto.

Saludos.