FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Pues simplemente declaras una propiedad en el objeto que recibe el mensaje del tipo que desees para tu evento. Lo más sencillo:
Cuando recibas el mensaje llamas al evento:
Un evento es una propiedad como cualquier otra salvo porque su tipo de datos es un método. Como en:
Si te conviene puedes definir el tipo de datos con más parámetros (o menos pues el consabido Sender no es estrictamente necesario): Por otra parte, ¿estás seguro de requerir un mensaje? Para que el primer combo mande un mensaje al segundo debe conocer el 'handle' de éste y si lo conoces entonces muy posiblemente conces al combo e sí de maner que por qué no poner el combo destinatario como propiedad del primero, si queires protegida para que no pueda accederse desde fuera. // Saludos |
#2
|
|||
|
|||
Evento nuevo en objeto
Gracias por la respuesta, y se me olvido decir que este evento lo quiero para mi forma y los componentes dentro de ella, la idea es que la forma responda a este evento, por medio del mensaje de algun componente y lo reenvie (la forma) a sus hijos (componentes) para que responda quien tenga que responder a este evento segun los valores que sean enviados, por ejemplo el caso de los combos, el primer combo al evento Onclick manda un mensaje al padre (en este caso la forma) y el padre lo reenvia a sus hijos, lo capta el segundo combo este hace lo que tenga que hacer y asi con cada componente, ¡ah! en cada "evento nuevo" de los componentes, quiero poner la condicion segun sea el caso:
Código:
if wparam=1 then if lParam=1 then instrucciones..... elseif lParam=2 then instrucciones |
#3
|
||||
|
||||
La respuesta de Roman es Correctísima (como siempre), quizás este ejemplo te aclare algo más:
El ejemplo que pongo a continuacion, es de un CheckListBox que tiene que informar a una ventana llamada FormDestino cuando se hace click en un elemento del CheckListBox.
Ahora solo queda recoger el evento.
Eso de que el padre (FormDestino) reenvie el mensaje a sus hijos (controles dentro de FormDestino), no lo veo claro. Para cada componente que uses, tendrías que crearle el evento TNotifyCheckClicks, y es bastante trabajo. Creo que es mejor centralizar todo el trabajo de los hijos en el procedimiento SetHechoClick. Saludos Saludos Última edición por Lepe fecha: 02-09-2004 a las 11:38:30. |
#4
|
|||
|
|||
Evento nuevo en objeto
Asi es Lepe, como ya me estoy adentrando mas en esto, ya me di cuenta que para lo que quiero es mejor crear mis componentes e incluir entre sus propiedades "mi evento", el ejemplo que me pones ( y no es por presumir, estoy aprendiendo ) ya lo habia hecho, pero no me gusto porque la idea es que.. bueno antes he de decir trabaje con Centura como lenguaje de programación y en este creaba un evento de usuario, este evento lo podia llamar en cualquier componente y lo que hacia era definirlo en los componentes que lo iban a utilizar(casi siempre eran todos incluyendo la Forma contenedora), dentro de este evento siempre manejaba wParam y lParam y por ejemplo si habia que limpiar los edit, combos o grid's que tuviera, le picaba al boton limpiar, este boton en su evento "MUsuario", enviaba un mensaje ej. SendMessage(Parent(HandleBotonLimpiar), MUsuario, 0,0) el 0,0 eran wParam y lParam respectivamente, este mensaje(MUsuario) era enviado a la Forma que contenia dichos componentes, esta a su vez cada que recibia un mensaje de este tipo lo reenviaba a todos sus componentes, algo asi como SenMessage( Child(HandleForma), MUsuario, wParam, lParam), y en mis componentes, como ya tenia definido el evento MUsuario, en cada uno tenia un codigo parecido a esto:
Código:
On_MUsuario if wParam =1 if lParam = 1 Myvalue:='' // elseif lParam=2 MyValue:=vArray[1] A mis componentes si lParam es 1 pues carga tu valor del array de campos, si es 2 quedate como estas, pero esto seria en cada "evento usuario" del componente y A mi Forma si lParam es 1 tu caption sera "alta", si es 2 "modificación", si es 3 "Consulta", la primera vez que haga esto, se que va a ser bastante trabajo, pero las demas solo tendria que pegar mis componentes y ya, para estandarizar, bueno la inquietud de esto es porque voy a trabajar con SqlServer y quiero llevarme a mis pantallas los datos de mis registros pero tratando de utilizar el menos ancho de banda posible, bueno estoy tratando de usar lo menos posible componentes db que siempre estan conectados a los datos, espero ir bien en esto si no ustedes me diran, la verdad me han ayudado bastante, bueno ya me extendi, saludos y gracias por sus respuestas. |
#5
|
||||
|
||||
Pues tal como lo describes puedes hacerlo prácticamente tal cual con Delphi. De hecho me he perdido un poco en la explicación y ya no sé si lo tienes o no resuelto.
Algunas ideas: Como creo que ya has observado tendrás que crear componentes (o descendientes de componentes) para poder manejar los mensajes. El punto es que Delphi traduce los mensaje tipo Windows (los que envías con SendMessage) en eventos pero no implementa uno genérico que tú puedas definir durante el diseño. Según he entendido, tú idea a grandes rasgos es como sigue: Cita:
que para mi gusto hace el código muy ilegible y difícil de mantener aun cuando no todas las componentes implementen todas las etiquetas. Quiero suponer que posiblemente WParam lo usas para el tipo de acción a realizar (limpiar, cargar, guardar, etc) y LParam afecta el cómo se realiza la acción. Lo primero entonces es separar las acciones en distintos mensajes:
y crear manejadores para cada mensaje:
Las componentes que no manejen una acción en particular simplemente no implementan el correspondiente manejador. Lo siguiente es convertir estos mesajes en eventos:
¿Por qué en eventos? Cada componente podría manejar de alguna manera estándar un determinado mensaje pero al convertirlo en evento se da la oportunidad al programador de modificar el comportamiento en tiempo de diseño. El parámetro Proceed quizá no te sea necesario pero ante algo tan general como lo que planteas yo lo pondría para poder parar el mensaje de ser necesario. La idea es: Una componente envía uno de estos mensajes al formulario quien normalmente lo pasará a todas sus componentes. El programador puede detener la transmisión del mensaje en el correspondiente evento del formulario poniendo Proceed := false si por alguna circunstancia ve que no conviene transmitirlo. Así mismo, cuando una componente recibe un mensaje, puede determinar no pasarlo a los que le siguen. Esto es similar, por ejemplo, a cuando intentas cerrar una aplicación MDI como Word. El sistema manda el mensaje WM_CLOSE a la ventana principal quien a su vez lo manda a todos los documentos. Si alguna de éstos tiene cambios sin guardar presenta un mensaje al usuario. Si éste decide cancelar entonces el mensaje WM_CLOSE ya no se sigue difundiendo. params en las declaraciones de arriba significa cualesquiera parámetros que consideres conveniente para la acción. Podrías usar WParam y LParam pero esto te deja un código poco legible. Considera que un mensaje como WM_KEYDOWN, Delphi lo connvierte a fin de cuentas en el evento OnKeyDown cuyos parámetros son mucho más entendibles. Ahora concretemos. Comencemos por el formulario, quien debe encargarse de transmitir los mensajes a todas sus componentes:
Finalmente vemos como sería el caso de una componente:
Desde luego queda la sensación de que estamos repitiendo todo lo que hace la VCL de Delphi con los mensajes de Windows pero bueno, es el resultado de querer algo tan genérico. // Saludos |
#6
|
||||
|
||||
Este, apreciado Román, es un artículo digno de una revista o de un buen libro de programación en Delphi. Te felicito por él, que será un verdadero pan para usuarios que quieren introducirse a la programación de componentes que responden a mensajes (del sistema o definidos por tu programa). Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#7
|
||||
|
||||
Cita:
No me convence. Realmente creo que el compañero LucianoRey debería repensar un poco su objetivo. Entiendo su necesidad de reusar código pero no me parece adecuado algo así tan general. Creo que a la larga es contraproducente. Realmente es muy difícil de saber sin más detalles de lo que realmente desea. Con la información que nos da la situación es muy confusa; en verdad me cuesta trabajo ver qué relación hay en todo esto con aligerar el ancho de banda para consultas a un servidor SQL Server. Creo que es demasiado abarcar. Aquello de usar los mismos mensajes para determinar si el formulario en sí dice 'alta', 'modificación' o 'consulta' no parece tener nada que ver con el comportamiento que otras componentes puedan tener ante los mensajes. Y no sólo eso; aunque no lo dice, suena a que va a utilizar el mismo formulario para por lo menos tres cosas distintas lo que seguramente implicará un uso extenso de condicionales para mostrar u ocultar determinados controles dependiendo del 'mensaje' que se le mande en lugar de usar herencia visual que deja un código mucho más prolijo. En fin, sin más detalles es imposible decir casi nada sensato. // Saludos |
|
|
|