8 respuestas en este tema

[TiammatMX]

Buen día/tarde/noche, según sea el caso...

Tengo un TMainMenu de hasta 3 niveles, el cual debe ser "descompuesto" en sus opciones integrantes, guardado en una tabla, leído y "rearmado" en un TTreeView. Sé que puede ser muy básico algo así, pero no tengo la más pálida idea de cómo hacer ésto.

Una complicación más es que no tengo la estructura de la tabla en la que serán guardados los datos de reintegración del menú, así que si pueden complementar con una estructura de tabla a proponer en su respuesta, les quedaré muy agradecido.

Una ilustración de cómo está actualmente éste menú.

Archivos adjuntos

•  4365_3b45d297db3a49c1270cac1db05e2ccc72ee5fda.jpg   29,36KB   8 descargas

[Delphius]

Hola Felipe,
A ver si entiendo... ¿un menú tiene como MAXIMO 3 submenus?
¿Existe una cantidad arbitraria de menúes?

No me queda en claro esto cuando dices: "tengo un TMainMenu de hasta 3 niveles". ¿A que te refieres com niveles?
Siendo precisos un TMainMenu no es más que una colección de TMenuItem, y éste a su vez puede o tener su propia colección de TMenuItem como submenú, y así al infinito.

Aclara por favor porque ni viendo la imagen te entiendo.
Me queda en claro que lo que buscas es armar el menú en tiempo de ejecución leyendo la información desde una base de datos.

De forma genérica, y que permita añadir una cantidad arbitraria de menúes e items es la siguiente, gracias al concepto de tabla autoreferenciada es posible eso:

delphi

+----------+
| MenuItem |-1---+
+----------+     |
      ^          |
      |          |
      +----------+

Básicamente la idea es que la tabla MenuItem tenga una clave foránea que se autoapunte a la clave primaria de si misma:

MenuItem
------------
IDMenu: PK
Texto
etc
MenuPadre: FK>>MenuItem.IDMenu

Entonces cuando un MenuItem tiene un valor NULL en el campo MenuPadre significa que se trata de un Menu simple, sin submenu. En otro caso, al leer dicho campo se tiene el ID del menú padre al que está referenciado y por tanto el MenuItem se trata de un submenu.

Esto es en forma genérica, y debo aclarar que no todos los motores permiten la autoreferencia (aunque la gran mayoría si lo soporta). Si me explicas mejor podría concebir otra forma de hacer tal relación.

Saludos,

[TiammatMX]

Hola Felipe,
A ver si entiendo... ¿un menú tiene como MAXIMO 3 submenus?
¿Existe una cantidad arbitraria de menúes?

No me queda en claro esto cuando dices: "tengo un TMainMenu de hasta 3 niveles". ¿A que te refieres com niveles?
Siendo precisos un TMainMenu no es más que una colección de TMenuItem, y éste a su vez puede o tener su propia colección de TMenuItem como submenú, y así al infinito.

Aclara por favor porque ni viendo la imagen te entiendo.

Exacto, por ejemplo, para Archivo/Catálogos/Catálogo1, Archivo/Catálogos/Catálogo2 ... Archivo/Catálogos/CatálogoN.

...Me queda en claro que lo que buscas es armar el menú en tiempo de ejecución leyendo la información desde una base de datos.

De forma genérica, y que permita añadir una cantidad arbitraria de menúes e items es la siguiente, gracias al concepto de tabla autoreferenciada es posible eso:

...

Bueno, no exactamente "armar" el menú, sino comprobar que el usuario que ha entrado tiene o no los permisos para usar o no un ítem del menú.

...

delphi

+----------+
| MenuItem |-1---+
+----------+     |
      ^          |
      |          |
      +----------+

Básicamente la idea es que la tabla MenuItem tenga una clave foránea que se autoapunte a la clave primaria de si misma:

MenuItem
------------
IDMenu: PK
Texto
etc
MenuPadre: FK>>MenuItem.IDMenu

Entonces cuando un MenuItem tiene un valor NULL en el campo MenuPadre significa que se trata de un Menu simple, sin submenu. En otro caso, al leer dicho campo se tiene el ID del menú padre al que está referenciado y por tanto el MenuItem se trata de un submenu.

Esto es en forma genérica, y debo aclarar que no todos los motores permiten la autoreferencia (aunque la gran mayoría si lo soporta). Si me explicas mejor podría concebir otra forma de hacer tal relación.

Saludos,

Ahora sí, el que se quedó pasmado fui yo, no entendí...    ¿Podrías ser un poco más específico? 

[Delphius]

A ver.... ¿N catálogos? Repito: un TMainMenu no es más que una forma árbol presentada en forma de menú:

delphi

MainMenu
 +
 |
 +---MenuItem1
 |    +
 |    |
 |    +---MenuItem11
 |    |    +
 |    |    |
 |    |    +-- ...
 |    |
 |    +---MenuItem12
 |    |    +
 |    |    |
 |    |    +-- ...
 |    |
 |    +---MenuItem13
 |    .
 |    .
 |    .
 |    +---MenuItem1N
 |
 +---MenuItem2
 |    +
 |    .
 |    .
 |    .
 |
 +---MenuItemM

¿Al final que son 3? ¿O son N? ¿Los menúes? Es decir el primer nodo (o nivel) del árbol... ¿Los submenúes?

Siendo más preciso aún con la terminología un menú es justamente un nodo de nivel 1 del árbol (lo que yo denominé como MenuItem1..MenuItemM). Es decir, usando como ejemplo una aplicación de ofimática: Archivo, Edición, etc.
Los submenúes son en realidad las opciones que vemos dentro de cada uno de estos. Para archivo: Abrir, Guardar, Guardar como, etc. Son los MenuItemXX que puse en el árbol.
Luego es que para cada uno de éstos es que se pueden crear una 2da rama de submenúes. Por ejemplo, para un hipotético "Pegar como" podríamos poner subopciones como "... Imagen", "... Texto", "Objeto OLE", etc.

Especifica adecuamente cual es la estructura de todo tu MainMenu en forma completa. Describe puntualmente cual de todo ese menu pretendes dar "dinamismo".

Pero si es como esto último que describes:

Bueno, no exactamente "armar" el menú, sino comprobar que el usuario que ha entrado tiene o no los permisos para usar o no un ítem del menú.

Entonces ya es otra cosa y me parece que la pregunta las has liado y llevado hacia otro lado. ¡Haber dicho antes! Creo recordar que ya en el foro se ha dicho sobre el tema, y hasta creo que se ha puesto un ejemplo.

Solución clásica: apoyarse en el uso de TAG. Asociar a cada opción del menú un valor numérico que indica el nivel mínimo permitido... luego en la tabla usuario asociarle justamente a su perfil un valor.
Al momento de mostrar el form simplemete se lee el valor que tiene el usuario y si el leído del usuario cumple la condición mayor o igual al de TAG se asume justamente que tiene dicho permiso. ¿Se entiende o lo explico de nuevo?

Saludos,

[Rolphy Reyes]

Saludos.

Desde mi punto de vista la estructura es bastante sencilla, la veo así:

Id
Descripcion
ParentId

En el ParentId guardas quien es el padre del ítem en cuestión.

Para poner el menú en un TreeView, pues adjunto unos fuentes de un componente gratuito que hace esa función.

Happy Coding!!

Archivos adjuntos

•  4374_45a536de6540fef1ba0405f0b89ce25664298cff.zip   20,77KB   4 descargas

[TiammatMX]

Saludos.

Desde mi punto de vista la estructura es bastante sencilla, la veo así:

Id
Descripcion
ParentId

En el ParentId guardas quien es el padre del ítem en cuestión.

Para poner el menú en un TreeView, pues adjunto unos fuentes de un componente gratuito que hace esa función.

Happy Coding!!

...y mira, yo complicándome la existencia... 

[TiammatMX]

...

...y mira, yo complicándome la existencia... 

Pues creo que tendré que continuar complicándome la existencia, por que el componentillo éste NO me permite hacer las llamadas a las pantallas correctamente, me manda una excepción al momento de crear la pantalla.

¿Más ideas, por favor?

[Rolphy Reyes]

Saludos.

TiammatMX, ¿Puedes mostrarnos como haces para llamar las ventanas?

[FerCastro]

...

...y mira, yo complicándome la existencia... 

Pues creo que tendré que continuar complicándome la existencia, por que el componentillo éste NO me permite hacer las llamadas a las pantallas correctamente, me manda una excepción al momento de crear la pantalla.

¿Más ideas, por favor?

Jelipe,

hace unos años trabajé con creación de menús en tiempo de ejecución partiendo de opciones desde una tabla. No se si te sirva, estoy en skype

Saludos!!