Si, Screens.Forms es la via rapida.
Sin embargo, el punto que se ve es que una aplicacion GUI tiene un form
principal, entonces crea forms secundarios que:
1- Pueden ser MDIChildren, o pueden ser hijas dentro de una aplicacion SDI,
o puden ser independientes (Owner y parent =nil)
2- Pueden ser modales. A la vez, o son dialogos, o son formas de edicion
3- Pueden ser embeidos (algunos les gusta meter forms dentro de forms, en
vez de usar Frames)
4- Tienen logica de muestra y cerrado muy variable
5- Pueden ser formas de multiple instancia (como los documentos en Word)
o DEBERIAN ser de unica instancia. A la vez, las de unica instancia TAL
VEZ son parte de un esquema MDI... o SDI?
6- Pueden ser ensambladas (ej: Un form contiene los frames de Edicion de
Frame Contacto + Frame campos de cliente + ...)
Las tecnicas tradicionales son ineficientes en el sentido que cada vez que
se hace una forma hija, estamos implementando una de estas ideas, o
muchas mas! Luego, no olvidar que ademas se necesitan sincronizar el
menu, las barra(s) de navegacion... Luego el problema de la reutilizacion.
Es dificil EXTRAER un Form bien hecho, que se necesita en otro proyecto
porque hay muchas dependencias o se olvida como es la logica y las reglas
de creado/destruccion.
Adicionalmente, las interfaces MDI se consideran "obsoletas" por algunos.
De hecho, una forma mas efectiva es usar una interface por tabs, como lo
hace Mozilla Firefox, VS.NET o el mismo Delphi.
Es por eso que es importante el link al framework simple de aplicaciones. La
idea es que uno crea un "modulo" (en mi caso, uso Frames pero igual da con
forms) y un Administrador de modulos se encarga de cubrir TODOS los
casos enumerados anteriormente. Luego, siguiendo el patron de
Factory/Builder, se hace algo como:
Código:
initialization
AdministradorModulos.Registrar('Editar Cliente',
TfrmEditarCliente,
TCategoria.Create('Editar Cliente','Archivo/Clientes','BarraClientes',IndiceIcono),
tipInstanciaUnica);
Y en cualquier parte cosas como:
Código:
AdministradorModulos.Mostrar('Editar Cliente');
resultado:=AdministradorModulos.MostrarModal('Editar Cliente');
AdministradorModulos.Clonar('Editar Cliente');
etc...
Lo cual se encarga de administrar los menus y barras, la logica de creacion
y destruccion declarativamente. Es MUY facil extraer los "modulos" y reusar
en otros proyectos.
Actualmente, tengo una version personalizada basada en esta idea, y
puedo decir que reuso sin problemas modulos con proyectos tan diferentes
como:
- Un ERP (mezcla todo)
- Un IDE de programacion para scripts (mas tipo MDI)
- Un formulario de administracion de los servidores (SDI, 2-3 formas y ya)
- Otros proyectos mas pequeños
Extraigo, reubico y reuso modulos de personalizacion, de claves, de edicion,
etc... sin lios...
La productividad se siente, y no me preocupo en si estoy haciendo bien la
creacion o destruccion, o como se hace todo... adicionalmente, el
administrador de modulos es portable entre D7 y D8 (ASP.NET) y he podido
hacer "transplantes" de componentes (probando con los de Delphi, los de
TMS y DevExpress, actualizando versiones, etc...) con un traumatizmo
minimo....
En fin, es meter TODO el conocimiento que expone Roman (muy bien
explicado) y dejarlo en un framework!