![]() |
Funcionalidad (Popup de ventanas abiertas)
buenas tardes
quisiera implementar lo siguiente a ver si me dan una mano imaginenos un menu Catalogos.... Operaciones......Reportes....etc... etc..... VENTANAS.... opcion1 opcion1 opcion1 opcion2 opcion2 opcion2 opcion3 opcion3 opcion3 en asunto es que si voy al menu operaciones y escojo la opcion 2 me gustaria que en el menu VENTANAS aparezca una opcion es decir cuando se abren muchas ventanas a veces uno se puede perder y el menu ventanas nos ayudara a "activar la ventana" que queramos me dejo entender? supongo que hay que crear el popup dinamicamente, la cosa es como "activar" de acuerdo a la opcion escogida en el menu Ventanas |
Para añadir Items al menú puedes hacer algo como esto:
Saludos. |
Pues si no recuerdo mal, y he entendido bien lo que pretendes, creo que esto es automático...
En el formulario principal debes asignar dos propiedades: -La propiedad Menu donde se le asigna el menú principal vinculado a la ventana -La propiedad WindowMenu que es el punto de menú donde se acumulan las ventanas creadas, y al clicar te devuelve la ventana seleccionada. Creo recordar que esto solo funciona con ventanas MDI(no estoy seguro) Saludos |
Una forma fácil de hacerlo manualmente es mediante el uso de la propiedad tag:
Y en los formularios secundarios colocar esto en el evento OnClose:
Automatizar esto requiere algo mas de trabajo pero se puede hacer con un par de clases y realizando sunclassing del formulario principal y de los secundarios. Saludos. |
Cita:
|
Cita:
Saludos. |
^\||/^\||/^\||/
|
Explico un poco más el sistema:
La idea más sencilla es hacerlo manualmente, de forma que se cree un MemuItem por cada formulario secundario y que cada Item tenga una forma de conocer su formulario asignado. Al mismo tiempo cada formulario debe conocer su MenuItem para proceder a su destrucción al cerrarse. La manera más sencilla de guardar estas cosas en el tag de cada componente mediante un puntero. De esta forma un OnClicMenuItem traería fácilmente a primer plano el formulario solicitado y si éste se cierra, podría destruir su MenuItem puesto que lo tiene guardado en su Tag.
En el formulario secundario pondremos el sigueinte codico en el evento OnClose:
Esto es muy sencillo pero para cada nuevo formulario que implementemos debe ser ajustado manualmente. Si queremos automatizar esto un poco más, nos tenemos que complicar un poco con técnicas de sunclassing del formulario principal y de los secundarios para ser capaces de responder a los mensajes WM_COMMAND enviados a los MenuItems del Formulario principal, responder apropiadamente y para conocer cuando se va a cerrar un formulario secundario. Saludos. |
Automatizando las cosas
Veamos la funcionalidad que buscamos: 1.- Añadir elementos al menú de forma automática al añadir formularios hijos nuevos. 2.- Respuesta automática al seleccionar una opción de menú, colocando su formulario en primer plano. 3.- Eliminación automática del menú, al eliminar un formulario hijo Con este planteamiento necesitamos controlar los mensajes que recibe el formulario principal para detectar el Mensaje WM_COMMAND que se envía al seleccionar una opción TMenuItem y hacer lo mismo en los hijos, esta vez para detectar WM_CLOSE. ¿Como hacemos esto? Esto requiere hacer SubClassing del formulario principal y de los hijos. Básicamente un SubClassing realiza un cambio en la función de tratamiento de mensajes Windows de una ventana para cambiar su funcionalidad. Hacer un SubClassing en delphi es muy sencillo pues los TWinControl disponen de una función privada y virtual denominada WndProc que equivale a la función de tratamiento de mensajes Windows a nivel API, es decir, maneja mensajes del tipo WM_PAINT y no eventos como OnPaint. A su vez y para facilitar el SubClassing a alto nivel, los TWinColtrol disponen de un puntero público a un procedimiento denominado WindowProc que apunta a WndProc. Si hacemos que WindowProc apunte a nuestra función de tratamiento de mensajes, ya hemos hecho el SubClassing, con una simple asignación. Vamos a comenzar por los formularios hijos. Generalmente un SubClassing no pretende reescribir toda la función de tratamiento de mensajes sino añadir o cambiar alguna cosa y aprovechar la función original de esa ventana (WndProc) para que haga el resto del trabajo. Es por ello que para cada formulario deberemos conocer su WndProc original y escribir un procedimiento específico para su SubClassing. Esto lo vamos a hacer con una clase de la que crearemos una instancia para cada formulario hijo. Dado queremos que los formularios hijos informen al formulario principal cuando se van a cerrar, lo primero que vamos a hacer es escribir una clase para realizar el SubClassing. Crearemos un objeto para cada formulario hijo dotándole de una nueva función de tratamiento de mensajes que será un procedimiento que llamaremos SubClassWndProc. Éste va a añadir funcionalidad al formulario y cederá el control a su WndProc original. Necesitamos tantas versiones de SubClassWndProc como formularios hijos y es por ello que lo encapsulamos en una clase de la que crearemos las instancias que nos hagan falta.
Como vemos, esto nos permite tratar WM_CLOSE y enviar al Formulario principal un mensaje personalizado WM_MYCLOSE que informa en WParam cual formulario hijo se va a cerrar. Luego cede el control al WndProc original que al ser privado, lo trampeamos con una clase interpuesta (TMForm). Como necesitamos una función SubClassWndProc para cada formulario hijo, crearemos una instancia para cada uno y las controlaremos en una lista TList. El SubClassing del formulario principal que es único, lo haremos sobre la clase o componente núcleo de nuestro sistema, y se dedicará a mnejar los mensajes W_COMMAND enviados desde el menú. También dará respuesta a nuestro mensaje personalizado WM_MYCLOSE, enviado desde un formulario hijo que se cierra. Esta sería la forma de tratar esos mensajes:
La funcionalidad completa que tendremos en nuestra clase TMultiWindowMenuControl será así:. 1.- Un cosntructor que capture el Formulario principal, prepare su SubClassing y cree un TList para almacenar objetos TSubclasWindow. 2.- Un destructor que también deshaga los SubClassing. 3.- Asignar el MenuItem principal del que colgaremos los MenuItem para los formularios hijos 4.- Un procedimiento Add para añadir un formulario hijo 5.- Un procedimiento Delete para eliminar un formulario hijo 6.- Un procedimiento Clear que elimine el control de todos los formularios hijos 7.- Una forma de encontrar el MenuItem señalado por el ID que proporciona WM_COMMAND y que llamará GetMenuItenPos 8.- Una respuesta al mensaje WM_MYCLOSE que libere la opcion de menu correspondiente. El código completo de la clase:
Ambas clases se colocarán un una sola unit y la funcionalidad será tan simple como tener un formulario principal con un menú que nos permita crear formularios hijos y con un MenuItem del que se colgarán los formularios hijos de forma automática. Además, tendrá un objeto de la clase TMultiWindowMenuControl.
No hay que hacer nada más para tener el control de los formularios hijos de forma automática en un menú. Todo el código lo he probado en delphi 7 y Berlin. En este enlace teneis el código y un ejemplo. Saludos. |
Tras descubrir un bug, me veo obligado a publicar su corrección. El método SetMenuItem queda como sigue:
El código completo corregido se encuentra aquí: MultiWindowMenuControl_01.zip. Saludos. |
¡¡¡Gracias!!! ^\||/
|
La franja horaria es GMT +2. Ahora son las 11:43:28. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi