FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Override eventos On...
Estoy intentando tener acceso a los eventos principales de un Form desde un componente que lo contiene, para poder sobrescribirlos al modo override o inherited.
La idea es disponer de un form de exploración DB tipo y convertirlo en componente. Pues bien, si yo llamo a este componente desde una Query, para editar los valores de algún dato en modo Tabla por ejemplo, y realizar un locate cuando el componente ha acabado su creación. Si accedo a la propiedad OnActivate, esta se sobrescribe sustituyendo, pero no complementando la original. Este componente es parecido al TDBViewer del curso de Luis Roche, pero quiero que en inspector de objetos me aparezcan los eventos tales como: OnActivate, OnShow, OnClose, OnDestroy. Actualmente lo consigo, pero los métodos antecesores desparecen y no se ejecutan en 'inherited', es decir: en herencia después de lo declarado en los eventos originales. ¿Cómo puedo declarar estos eventos en mi componente de enlace? Ya pego el código del compo para que lo probéis si queréis con cualquier Form al uso. Si queréis más código me lo pedís. ¿Vale? El código imprescindible de la llamada del Componente en el form que creamos dinámicamente es: Jolines: Que bonitas quedan las etiquetas "Delphi". Ahora el código del componente en si: ¡¡Gracias a todos!! Última edición por lento manu fecha: 05-10-2005 a las 17:57:36. |
#2
|
||||
|
||||
¿Y si en Lugar de TComponent, derivas de TControl (que tiene esos eventos)?
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#3
|
|||
|
|||
Probado:
Gracias, es una gran idea.
He hecho la prueba: En el form desaparece el componente como icono y queda como un control invisible: única diferencia en diseño. En ejecucíón pasa lo mismo. El código que debe ejecutarse en el form que contiene OnActivate, por ejemplo, se omite en espera de un nuevo código en el uso del compo ¡desprotejiendo así toda su codificación! |
#4
|
|||
|
|||
Solución a Sobreescibir Eventos en Componentes
He encontrado una solución, que funciona, pero no he conseguido un override sobre el evento, ya que el componente que abre el form, es un simple Tcomponent, no tiene este mismo valor en herencia. Tampoco he conseguido un inherited. La llamada
crea un Form que ha su vez es un inherited de otro inicial. Este form tiene en el OnActivate las llamadas, que generan controles DBtext, DBimage, DB... lo que sea. Estas llamadas se inician en el evento OnActivate. Os pego el código porque creo os puede interesar (si veis algo mal, avisarme, por favor). Gracias por las ayudas recibidas. Espero que esto pueda servir para alguien. Última edición por lento manu fecha: 05-10-2005 a las 17:59:15. |
#5
|
|||
|
|||
Lo que puedes hacer es crear unos campos privados en tu componente, del mismo tipo que los eventos que necesitas. Por ejemplo, el OnActivate:
Entonces al crear el formulario haces algo como:
Y en el método activate haces:
Lo que se hace aquí, es guardar el antigüo manejador de evento, y luego, si este estaba asignado, hacer la llamada... Espero que esto te ayude a solucionar tu problema... Saludos... Última edición por maeyanes fecha: 30-09-2005 a las 22:04:41. |
#6
|
|||
|
|||
Gracias Mareyanes
Gracias Marcos. Si me ha servido, por supuesto. Sobre todo a que el código esté claro, no contenga la redundancia que contenía al repetir las llamadas internas de un evento ya escrito. No sospechaba ni en lo más remoto que
pudiera funcionar, todavía no comprendo bien por qué funciona, pero ya me entrará en la cabezota. El comportamiento, después de los cambios que me sugieres, es de hecho, el mismo. Quiero decir, que en el Inspector de Objetos, me aparece el evento OnActivate, que por lo menos, ejecuta el evento asociado en el form que se creará, pero si escribo código en este evento, que necesito para realizar un locate, este no se ejecuta, aunque lo escriba con inherited. Si tienes alguna idea... ...Acabo de probar esto y EUREKA: funciona. Evidentemente por eso me has recomendado utilizar una nueva variable FOldOnActivate, para mantener la heredada y la propia. Dejando el procedimiento así, se me ejecutan ambas: Muchísimas gracias por el empujoncito: me he estampado con lo que iba buscando. |
#7
|
|||
|
|||
Componente en si
Por si a alguien le interesa, este es mi componente final (de momento) que genera un Explorador TTable o TAdoTable, pero se puede aplicar a cualquier gestion SQL genérica con TQuery en vez de TTable. El asunto es crear un superForm dedicado a una conexión DB:
Espero que os pueda servir. |
#8
|
||||
|
||||
¿Y este compadre?
Explorador: TfmExControlsTabla; saludos, tiene buena pinta. |
#9
|
|||
|
|||
lo que genera
Ese es precisamente el Form que se genera y q se declara en el uses:
DBGridCheck, ExControlsTabla //TfmExControlsTabla; El DBGriDCheck es un TFrame contenido en el form ExControlsTabla, que esencialmente es toda una aplicación que edita indices, busquedasy filtros, ademas de crear los controles DBImage, DBtext y todos los que quieras. Como una imagen vale + que 1000 palabras vamos a intentarlo: http://img386.imageshack.us/img386/8023/dbx5sl.jpg De modo que pasamos una tabla de un DataModule (en el metodo execute asi: Explorador:= TfmExControlsTabla.CreateTabla(Owner, FTable); ) que tiene sus campos Lookup y otros, personalizados en el doble click del TTable. Solo diseñamos la conexión, el formulario ExControlsTabla, genera edición de campos Blob, y todo lo que queramos escribir. Última edición por lento manu fecha: 06-10-2005 a las 12:23:34. |
#10
|
||||
|
||||
Execute es publico, por tanto el usuario puede llamarlo varias veces ok¿?, vale, lo llamo una vez, se crea el Explorador. Lo llamo una segunda vez, se vuelve a crear otro Explorador ¿y que pasa con el anterior? pues simplemente se queda perdido en memoria ram, ocupando memoria y sin que nadie lo pueda liberar, ya que Explorador apunta ya al nuevo creado. solución:
saludos |
#11
|
|||
|
|||
execute
De nuevo gracias, Lepe, por leerte tan bien el código. Tienes toda la razón, siempre que este llamando el método create desde la propiedad FModal=True. Quizá ha sido un error implementar la creación Modal o NoModal del form Explorador. Si es modal, la aplicación no permite crear ningún 'Explorador' más, ya que no tenemos foco para ello, pero no estaría de más protegerlo además con un Exit (eliminando la opción NoModal):
Si no quisiera, 'caprichos de usuario', editar en Modal, entonces se generan con el mismo componente tantos exploradores como llamadas haga, desde por ejemplo un menú de Exploración multitabla: El grave problema o error es que estoy usando Owner como como antecesor de todas esas ventanas, muy peligrosas, que se autodestruyen al morir el form donde reside este componente DBexplorador, posiblemente sería mejor Self, si asigna el compo en si como propietario o Padre. Tendía que hacer las pruebas: Hecho: ningún problema de momento ...Han colado las NoModal apagando desde la principal. |
#12
|
||||
|
||||
Cita:
Pues quitalos del TDBExplorer y dejalos en TExControlsTabla. No es una buena práctica en OOP modificar cosas que no te pertenecen Igual que haces con la propiedad Table, haces con la propiedad Explorardor, pasandolo de public a published. saludos |
#13
|
|||
|
|||
cambiar a Published
Seguramente es una gran idea, y supone rescribir un poco. Y sobre todo testearlo, pero posiblemente la lógica sea más sólida.
De nuevo gracias por tus valoraciones y consejos. Lo intentaré en cuanto pueda. De todos modos, el objeto es el que crea el complejo Explorador, basados en el form TfmExControlsTabla. A simple vista me parece difícil, lo q comentas, sobre todo para editarlo, pero sin probarlo, no lo puedo saber. Voy a intentar maquetearlo todo + simple, a ver q pasa. |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
|