13 respuestas en este tema

[egostar]

Índice

Introducción
Parte I. Programación Básica
Parte II. Modificando la interfaz Gráfica "básica"
Parte III. TActionManager en Acción
Parte IV. Modificando la "nueva" Interfaz Gráfica
 
 
 
Introdudcción
 

Seguramente en algún momento de tu vida de programador has usado el componente TMainMenu para diseñar tus menús de sistema o has utilizado componentes como TButton, TSpeedButton, TBitBtn, etc.. para ejecutar acciones en tus programas.  Sin embargo, a pesar de ser algo "normal" esta forma de trabajar con los eventos de un objeto, a la larga nos puede provocar mas trabajo que ventajas cuando deseamos rediseñar la interfaz gráfica de nuestras aplicaciones.

¿Por que digo esto? Bueno, cuando deseamos modificar la interfaz gráfica de nuestras aplicaciones y queremos por ejemplo, eliminar un TMainMenu y en su lugar crear botones tenemos que "transferir" el código escrito en los eventos del menú a los botones que vamos a crear, si nuestra aplicación es muy simple no tendrí­amos ningún problema en hacer esto, pero si nuestro proyecto contiene decenas de eventos esto llegarí­a a ser una actividad titánica y con un margen de error muy alto dependiendo de la complejidad de nuestro proyecto.

Para ello, Delphi nos obsequia un componente de nombre TActionManager, que tiene como objetivo principal el de separar la interfaz gráfica de nuestra lógica de negocio, es decir vamos a obtener una aplicación de dos capas (la capa visual y la capa lógica) algo que desde mi punto de vista es muy funcional e interesante.

Parte I. Programación Básica
 

Para iniciar este tutorial vamos a crear una aplicación tí­pica con un TMainMenu para después entrar de lleno con el componente TActionManager

Pegamos en nuestra forma los siguientes objetos:

1 TMainMenu
2 TEdit
4 TLabel

Agregamos las opciones: (Suma,Resta,Multiplicación,División,Salir) en nuestro TMainMenu.


 

 

Escribimos el codigo de los eventos a cada una de las opciones de nuestro menú, que en este ejemplo vamos a tratar de hacerlo muy básico.
 
 

delphi

procedure TForm2.Divisin1Click(Sender: TObject);
begin
  label1.Caption := format('%f',[strtoint(edit1.Text) / strtoint(edit2.Text)]);
end;
 
procedure TForm2.Multiplicacin1Click(Sender: TObject);
begin
  label1.Caption := format('%d',[strtoint(edit1.Text)*strtoint(edit2.Text)]);
end;
 
procedure TForm2.Resta1Click(Sender: TObject);
begin
  label1.Caption := format('%d',[strtoint(edit1.Text)-strtoint(edit2.Text)]);
end;
 
procedure TForm2.Suma1Click(Sender: TObject);
begin
  label1.Caption := format('%d',[strtoint(edit1.Text)+strtoint(edit2.Text)]);
end;
 
procedure TForm2.Salir1Click(Sender: TObject);
begin
  close;
end;

Compilamos y ejecutamos nuestro programa ejemplo y deberá de funcionar correctamente
 

Parte II. Modificando la interfaz Gráfica "básica"
 

Ya tenemos creada una pequeña aplicación con el tí­pico Menú, pero que pasa si ahora deseo cambiar el formato de mi interfaz gráfica eliminando el TMainMenu y en su lugar mostrar botónes para ejecutar las operaciones.

Los pasos a seguir serí­an:

Eliminar el objeto TMainMenu, agregamos 5 TButton y asignamos en la propiedad caption  de cada botón la operación correspondiente, algunos lo que hacemos es asignar el nombre en la propiedad name del objeto para que evitar "dolores de cabeza" a la hora de identificar los objetos.

 

Posteriormente tenemos que "transferir" el código asignado a cada una de las opciones del TMainMenu a cada uno de los botones.
 

Esta tarea como ya les mencioné, en aplicaciones pequeñas no tendriamos mucho problema para hacerlo, pero, en aplicaciones grandes esto serí­a una tarea bastante laboriosa y con cierto margen de error.

 
Parte III. TActionManager en Acción
 


Ya hemos visto el uso de los componentes básicos y sus eventos, ahora veremos las grandes diferencias y las ventajas de usar el componente TActionManager.

Para comenzar vamos a crear una nueva aplicación y agregamos los siguientes componentes:

1 TActionManager
2 TEdit
4 TLabel
 

Damos doble clic en el componente TActionManager y veremos una ventada donde vamos a agregar las acciones que queremos realizar dando clic en el botón New Action (Ins), vamos a realizar el mismo ejemplo que con los componentes básicos por lo que crearemos 5 acciones en el editor del TActionManager.

Para comenzar ordenadamente, vamos a asignar el nombre de cada una de las acciones en la propiedad Name en el inspector de objetos como se muestra en la siguiente figura:
 

Escribimos el código en cada una de las acciones del TActionManager dando doble clic en cada una de ellas, quedando de la siguiente forma:
 

delphi

procedure TForm2.DivisionExecute(Sender: TObject);
begin
  label1.Caption := format('%f',[strtoint(edit1.Text) / strtoint(edit2.Text)]);
end;
 
procedure TForm2.MultiplicacionExecute(Sender: TObject);
begin
  label1.Caption := format('%d',[strtoint(edit1.Text)*strtoint(edit2.Text)]);
end;
 
procedure TForm2.RestaExecute(Sender: TObject);
begin
  label1.Caption := format('%d',[strtoint(edit1.Text)-strtoint(edit2.Text)]);
end;
 
procedure TForm2.SumaExecute(Sender: TObject);
begin
  label1.Caption := format('%d',[strtoint(edit1.Text)+strtoint(edit2.Text)]);
end;
 
procedure TForm2.SalirExecute(Sender: TObject);
begin
  close;
end;

Hasta este punto ya hemos terminado con la capa lógica de nuestro proyecto, ahora procederemos a "diseñar" la capa visual y para ello comenzaremos por crear una nueva categorí­a donde estarán agrupadas nuestras acciones.

Seleccionamos cualquier acción y en la propiedad Category de la acción en el inspector de objetos "escribimos" el nombre de la categorí­a que deseamos (por ejemplo Menu) y automáticamente la acción seleccionada pertenecerá a dicha categorí­a.
 

http://egostar.delph...s/Categoria.PNG

Como podemos observar, la acción suma ya no está en el bloque de acciones sin categorí­a, ahora seleccionamos las demás acciones y le asignamos la categorí­a Menu.
 
 

Ya tenemos agrupadas todas nuestras acciones en la categorí­a Menu, ahora decidamos como vamos "mostrar" nuestras acciones, vamos a diseñar un Menú de acciones como si fuese el componente TMainMenu.

En el editor de acciones del TActionManager vamos a la pestaña ToolBars y creamos una nueva Barra de Herramientas.
 

http://egostar.delph...es/ToolBars.PNG
Ahora, regresamos a la pestaña Actions y "arrastramos" la categorí­a Menu en la Barra de Herramientas que se ha creado.

http://egostar.delph...s/Arrastrar.PNG

Como podemos observar, ya tenemos un Menú igual que lo teniamos con el componente TMainMenu, con la diferencia que en este momento el programa ya puede ser ejecutado y con las opciones del Menú ligadas a cada una de sus acciones, además de que los caption de las opciones del menú ya tienen el nombre correspondiente a cada una de ellas.

Compilamos y corremos nuestro programa y deberá funcionar igual que con el TMainMenu.
 
Parte IV. Modificando la "nueva" Interfaz Gráfica
 

Una de las ventajas principales del componente TActionManager como ya lo mencioné, es la de separar la capa lógica de la capa visual de nuestros proyectos, de tal forma que modifcar nuestra interfaz gráfica es por demás sencilla.

Con el mismo ejemplo de sustituir el menú de acciones por botones, vamos a proceder de la siguiente forma:

• Eliminamos la barra de herramientas donde tenemos nuestras acciones, no nos preocupemos que nuestro código no tiene ninguna relación con dicha barra.
• Agregamos 5 botones en nuestra forma
• Asignamos la propiedad Action de cada botón con la acción que deseamos sea ejecutada.

Como pueden observar, el botón automáticamente cambia su propiedad Caption con el nombre de la acción, hacemos esto para todos los botones.
 

 
En este momento todo el código escrito en las acciones del TActionManager está automáticamente asignado a cada botón, si ejecutamos nuestra aplicación, veremos que el sistema es ejecutado sin haber "transferido" ninguna lí­nea de código lo que nos muestra que usar este componente, además de estandarizar nuestra aplicación nos brinda mayor flexibilidad para modificar nuestra interfaz gráfica con un mí­nimo de esfuerzo.

Existen otras ventajas al usar este tipo de programación como puede ser la distribución de trabajo en equipo, es decir, mientras un programador se dedica al desarrollo de la capa lógica otro puede estar a cargo del diseño de la capa visual.

Con esto terminamos este tutorial básico del uso del componente TActionManager, en un futuro publicaré mas ventajas de este excelente componente.
 

html5

#indice

 


Salud OS

[Delphius]

Ayer leí­ tu hermoso y presentable artí­culo y me olvidé de ponerte calificación: 10 sobresaliente felicitado (no me puedo quitar lo de maestro... hoy estuve renegando con mi hermana tratando de explicarle divisiones con decimales ... ¡y lo que me costó recordar el tema! ).

Nunca he usado al componente. Sabí­a más o menos como viene la mano de su uso: asociar a los controles sus acciones mediante la propiedad Action... pero nunca pensé que con él se podrí­a crear de forma tan simple y elegante un menú. ¡Asombroso! Mi lección del dí­a .

Saludos,

[Rolphy Reyes]

Ayer leí­ tu hermoso y presentable artí­culo y me olvidé de ponerte calificación: 10 sobresaliente felicitado (no me puedo quitar lo de maestro... hoy estuve renegando con mi hermana tratando de explicarle divisiones con decimales ... ¡y lo que me costó recordar el tema! ).

Nunca he usado al componente. Sabí­a más o menos como viene la mano de su uso: asociar a los controles sus acciones mediante la propiedad Action... pero nunca pensé que con él se podrí­a crear de forma tan simple y elegante un menú. ¡Asombroso! Mi lección del dí­a .

Saludos,

Amigo, si no usas este componente ¿por lo menos usas el ActionList?.

Ya no me imagino tener que desarrollar pantallas comunes sin un ActionList.... 

[egostar]

Hola amigo Delphius

Me da mucho gusto que te haya gustado y sobre todo que te haya servido de lección , se que me falta mucho para dominar la didáctica, pero pues la lucha se hace .

Estoy preparando algunas caracterí­sticas adicionales de este componente que seguro van a dejar una muy buena impresión.

Salud OS

[egostar]

Amigo, si no usas este componente ¿por lo menos usas el ActionList?.

Ya no me imagino tener que desarrollar pantallas comunes sin un ActionList.... 

Hola amigo Rolphy

Sabí­as que el TActionManager es un TActionList pero con mucho mas funciones ?????

Salud OS

[broma]Espera que termine el próximo tutorial, vas a dejar de usar el ActionList [/broma]

[Rolphy Reyes]

Hola amigo Delphius

Me da mucho gusto que te haya gustado y sobre todo que te haya servido de lección , se que me falta mucho para dominar la didáctica, pero pues la lucha se hace .

Estoy preparando algunas caracterí­sticas adicionales de este componente que seguro van a dejar una muy buena impresión.

Salud OS

Amigo Egostar, como dicen en mi barrio: Bien ahí­!!!

Lo importante de todo es que estas echando el "pleito", más adelante con la practica te haras mejor maestro.

[Rolphy Reyes]

Amigo, si no usas este componente ¿por lo menos usas el ActionList?.

Ya no me imagino tener que desarrollar pantallas comunes sin un ActionList.... 

Hola amigo Rolphy

Sabí­as que el TActionManager es un TActionList pero con mucho mas funciones ?????

Salud OS

[broma]Espera que termine el próximo tutorial, vas a dejar de usar el ActionList [/broma]

Espero por el próximo tutorial y que puedas convencerme 

[egostar]

Espero por el próximo tutorial y que puedas convencerme 

Ve preparandote para el cambio amigo, solito te convenceras, ya lo veras

Salud OS

[Delphius]

Amigo, si no usas este componente ¿por lo menos usas el ActionList?.

Ya no me imagino tener que desarrollar pantallas comunes sin un ActionList.... 

Pues hasta el momento no. Pero en un desarrollo serio si lo pondrí­a en práctica... aunque, no se... todaví­a hay cosas que no me cierran del todo (en un sentido filosófico).

Me consta que con componentes que manejan y administran TAction se consigue un acoplamiento débil sin perjudicar ni perder la cohesión. Más considero que son un esfuerzo extra si se tiene ya una interfaz estable y en donde un acomplamiento lógico-interfaz no es del todo un problema.

Algo que me ha costado aprender muchí­simo es la aceptar que el acomplamiento no es el problema, sino lo débil o fuerte que sea.

Considero que el uso de "Acciones" es más útil donde se espera cierta dinámica en cuestiones de interfaz, por decir algunos ejemplos: el tener muchos controles que invocan a una acción: menues, barras) Algo como cualquier herramienta de la Suite Office, donde existen diferentes caminos de hacer la misma acción.
Si mi diseño es simple, y no se requiere de tanta dinámica y tiene una lógica simple optarí­a por evitarme el uso de acciones.

No se si me explico.
Usarlos por usar... no lo considero una buena regla.

Hola amigo Delphius

Me da mucho gusto que te haya gustado y sobre todo que te haya servido de lección , se que me falta mucho para dominar la didáctica, pero pues la lucha se hace .

Estoy preparando algunas caracterí­sticas adicionales de este componente que seguro van a dejar una muy buena impresión.

Salud OS

Pues si, me ha servido para comprenderlo mejor... y tal vez investigue más y mejor. Quizá considere su uso. Aunque tengo que analizarlo mejor. Tu sabes como soy: re analizo primero, y luego la práctica.

Estaré esperando tus avances.

Saludos,

[cHackAll]

Esto quedo bien hombre, gracias por hacernos conocer de esa forma tan digerible al componente

[egostar]

Esto quedo bien hombre, gracias por hacernos conocer de esa forma tan digerible al componente

Hey Little Bro, muchas gracias por la nota , trataré de mejorara mi didática en las próximas "entregas", porque ni a mi me gusta jejejeje

Algún dí­a

Salud OS

[egostar]

Pues hasta el momento no. Pero en un desarrollo serio si lo pondrí­a en práctica... aunque, no se... todaví­a hay cosas que no me cierran del todo (en un sentido filosófico).

Me consta que con componentes que manejan y administran TAction se consigue un acoplamiento débil sin perjudicar ni perder la cohesión. Más considero que son un esfuerzo extra si se tiene ya una interfaz estable y en donde un acomplamiento lógico-interfaz no es del todo un problema.

Algo que me ha costado aprender muchí­simo es la aceptar que el acomplamiento no es el problema, sino lo débil o fuerte que sea.

Considero que el uso de "Acciones" es más útil donde se espera cierta dinámica en cuestiones de interfaz, por decir algunos ejemplos: el tener muchos controles que invocan a una acción: menues, barras) Algo como cualquier herramienta de la Suite Office, donde existen diferentes caminos de hacer la misma acción.
Si mi diseño es simple, y no se requiere de tanta dinámica y tiene una lógica simple optarí­a por evitarme el uso de acciones.

No se si me explico.
Usarlos por usar... no lo considero una buena regla.

Pues si, me ha servido para comprenderlo mejor... y tal vez investigue más y mejor. Quizá considere su uso. Aunque tengo que analizarlo mejor. Tu sabes como soy: re analizo primero, y luego la práctica.

Estaré esperando tus avances.

Saludos,

Hola amigo Delphius

Se que eres analí­tico de profesión , pero no entiendo porque dices que este componente tiene un acoplamiento debil, ¿me puedes ilustrar con mas datos?. Por otro lado el uso de este componente no es privativo de aplicaciones ofimaticas.

En lo que si tienes razón es decir que cuando ya tenemos una aplicación estable y querer cambiar la lógica a este componente pudiese llegar a ser complejo, sin embargo, en aplicaciones nuevas este componente te beneficia al estandarizar tus acciones.

Salud OS

[JandoK]

orales.. pues a mi me parecio muy buena tu explicacion 

y quedamos en espera de la segunda parte...

salu2!!!!!!!

[Delphius]

Hola amigo Delphius

Se que eres analí­tico de profesión , pero no entiendo porque dices que este componente tiene un acoplamiento debil, ¿me puedes ilustrar con mas datos?. Por otro lado el uso de este componente no es privativo de aplicaciones ofimaticas.

En lo que si tienes razón es decir que cuando ya tenemos una aplicación estable y querer cambiar la lógica a este componente pudiese llegar a ser complejo, sin embargo, en aplicaciones nuevas este componente te beneficia al estandarizar tus acciones.

Salud OS

No dije que el componente tenga acoplamiento débil, sino que su uso nos permite llegar a un acoplamiento débil; que dicho sea de paso... es lo que se busca: mermar el acoplamiento.

Hay dos conceptos, como debes saber: acoplamiento y cohesión que son el Yin y el Yang de nuestra actividad.
Se busca dismiuir el acoplamiento, y aumentar la cohesión.

En este caso, el uso de TActionManager y/o cualquier componente que administre, controle y trabaje con objetos TAction ofrece la ventaja de conseguir un bajo acoplamiento entre diferentes controles.

Un control, mejor dicho una clase, de por sí­ no tiene acoplamiento. El acoplamiento se da en la interacción entre módulos. Podemos entender a un módulo como una clase, o un objeto incluso. En este caso, delegamos cierta responsabilidad lógica a un objeto de carácter más visual a un objeto especializado para ello, y con ello estamos relacionando (acoplando) un TActionManager con algún control.
Este acoplamiento en general es débil puesto que el ActionManager simplemente hace de mediador  (tal vez se lo podrí­a considerar una Fachada) entre los controles visuales y las acciones. Al haber conseguido acoplamiento débil, en algún lado debemos haber ganado cohesión... justamente dentro de TActionManager: centramos cohesivamente las funciones en un sólo punto.
Si pudieramos verlo en un diagrama de clase verí­amos algo así­: al menos un cliente, un TActionManager, y vinculados a éste uno o más TAction:

[tt]
+---------+ *        1 +----------------+  1      * +---------+
| Cliente |------------| TActionManager |<>----------| TAction |
+---------+            +----------------+            +---------+
[/tt]

Básicamente, la explicación breve es: trasladamos ese alto acoplamiento entre los clientes y las acciones, hacia otro punto, y ponemos en el medio a modo de mediador.
Si te fijas, ahora quien tiene el alto acoplamiento es el TActionManager, quien es el único que entiende a los TAction.