Delphi, marcos contra formularios. ¿Qué pasa con la interfaz de múltiples documentos?

Question

ayer comencé la discusión sobre "MDI vs interfaz con pestañas". Me he preguntado si debo continuar desarrollando mi aplicación como basada en MDI, o si debo insertar los formularios secundarios en hojas de pestañas. Alguien señaló que debería usar TFrames en su lugar ... Mi pregunta es: ¿por qué?

¿Cuáles son las ventajas de utilizar TFrames al incrustar el formulario sobre TFrame? Hasta ahora no conozco a ninguna, el cambio sólo me obligan a reescribir algunas partes del código ...

(que no voy a utilizar la incrustación en tiempo de diseño de todos modos!)

Gracias de antemano

Answer 1

Respondiendo al comentario de proporcionar una razón por utilizar marcos:

Me considero marcos a ser la construcción de bloques de la interfaz gráfica de usuario, con el tiempo de diseño combinación de componentes existentes con componentes más avanzados. Antes de Delphi 5, uno habría usado un descendiente TCustomPanel con controles secundarios y lo habría registrado como el nuevo componente, listo para colocarse en un formulario. Los marcos permiten lo mismo con menos problemas.

Le permiten concentrarse en desarrollar exactamente la funcionalidad que necesita, y nada más. Si lo hace bien, puede insertarlos en hojas de control de pestañas, en diálogos modales o no, en marcos secundarios MDI y en marcos estándar. Incluso puede agregar varios de ellos en una sola forma, algo que probablemente no haría con formularios incrustados. El punto es que para una reutilización máxima a menudo es necesario un enfoque en capas, y los marcos ayudan con eso.

Un marco es apto para la incrustación desde cualquier lugar. Se debe adaptar un formulario para que no muestre una barra de subtítulos y un borde, normalmente uno anularía el CreateParams() y ajustaría el estilo de ventana en consecuencia. Hay muchas más propiedades de formulario en el inspector que simplemente no tienen sentido para una forma incrustada. En mi humilde opinión, uno debe usar la entidad más básica y genérica que sea suficiente. Una forma simplemente es mucho más que un contenedor de control para incrustar.

OTOH No conozco ninguna desventaja de incrustar un marco que la incrustación de un formulario no tendría.

Editar:

Hay un comentario en relación con eventos como OnCreate o OnShow que las tramas no tienen. En realidad, consideraría esa otra ventaja de los marcos, ya que los manejadores de eventos no tienen parámetros, por lo que muchas cosas se codifican de forma rígida, necesariamente.

Consideremos el caso de configuración por usuario: en OnCreate no hay mucha información disponible, por lo que uno siempre termina usando una constante o el nombre de la forma de la sección de archivos INI, por lo que es muy difícil o incluso imposible reutilizar la forma o para crear varias instancias de ella. Con marcos, por otro lado, un método LoadSettings es la forma obvia de hacerlo, y puede llevar los parámetros necesarios. De esta forma, el control vuelve a donde pertenece, al contenedor del marco/forma incrustado. La reutilización solo es posible si el comportamiento se puede ajustar desde afuera.

Para objetos contenidos que no son componentes y necesitan gestión de por vida, existen, por ejemplo, AfterConstruction y BeforeDestruction.

Answer 2

Los marcos son buenos cuando desea repetir un "formulario secundario" varias veces en un formulario. No los usaría para interfaces con pestañas, ya que la forma incorporada es una mejor solución para el uso de interfaz MDI/Tabbed.

Answer 3

Tal vez usted encontrará algunas respuestas en este tema: gui-design-multiple-forms-vs-simulated-mdi-tabs-vs-pagecontrol

Answer 4

Tuve la misma decisión hace algunos años para una de nuestras aplicaciones, queríamos que se viera con formas incrustadas, primero utilicé los marcos y escribí una clase para gestionarlo.

Más tarde encontré el componente TLMDDisplayForm de LMDTools, lo que hace que insertar formularios dentro de él sea una tarea muy fácil, redujo el código utilizado y tenemos más características.

Uno de los principales objetivos que cambiamos de los marcos a Forms faltan algunos eventos de TForm como: OnCreate, OnShow, OnActive que usamos para algunas tareas en nuestras aplicaciones, además de algunas propiedades como: ActiveControl y otras cosas que no recuerdo

Si desea ir con las formas, le sugiero que utilice LMDTools que hacen la tarea más fácil para usted, junto a la versión básica es gratuita :-)

Answer 5

Para las formas dinámicamente insertadas/marcos yo personalmente prefiero usar formularios incrustados sobre marcos Varias versiones de cuando uno editaba un fotograma que estaba configurado como alClient, el fotograma cambiaría el tamaño entre ediciones y cualquier control que estuviera alineado específicamente a la derecha del fotograma cambiaría de posición. Cuando usé formularios incrustados, esto no sucedió, así que hice el cambio. Creo que este problema ahora está arreglado con las versiones posteriores de Delphi.

Estoy totalmente de acuerdo con los puntos que Mghie hizo anteriormente con respecto a la imposibilidad de pasar información al formulario incrustado a través de eventos de notificación. Para resolver esto, generalmente implemento una serie de interfaces en cada forma integrada para la comunicación. Esto realmente simplifica el código y permite implementaciones más genéricas en las que tiene un único "contenedor" que tratará con muchos tipos diferentes de formularios/marcos integrados. Algunos ejemplos de esto están disponibles en mi blog como parte del marco de asistente que diseñé.

Answer 6

Marco utiliza la carga más rápida y sin demora al crear el marco.

Pero el marco debe tener un elemento primario para incrustarlo. Desventaja sin eventos onCreate o onShow se ha activado. pero se puede llamar con el mensaje de gatillo OnShow caso como éste:

poner en sección privada del marco:

procedure CMShowingChanged(var M: TMessage); message CM_SHOWINGCHANGED; 

y luego crear el código como el siguiente:

procedure TFrame1.CMShowingChanged(var M: TMessage); 
begin 
    inherited; 
    if Showing then 
    begin 
    // .... put your code for onShowing is triggered 
    end 
    else 
    begin 
    // .... put your code for onHiding is triggered 
    end; 
end; 

esperanza puede ayudar usted debe considerar el marco incrustado para la GUI.

Puede considerar combinar con PageControl para controlar la apertura de su marco.

Manz

Answer 7

creo que deben utilizarse ambas. Por ejemplo, tengo un marco "estándar" que tiene los componentes dbnavigator, dbgrid y datasource, que es muy útil para la navegación de datos típica. En lugar de insertar tales componentes cada vez, inserto un marco que también tiene la capacidad de exportar sus datos (con JVCL: D) a varios formatos ... pero sé lo que quiero mostrar en el momento del diseño, así que sugiero una muy regla fácil: si se conoce en tiempo de diseño, use marcos; de lo contrario, use formularios incrustados.

Sin embargo, tenga en cuenta que los formularios no fueron diseñados para ser incrustados. Usándolos así, es antinatural (como dice un vampiro cuando entierra a su hija de 80 años y se veía como 30: D). La forma incrustada sabe poco acerca de la que lo posee y también (lógicamente) puede asumir que no está incrustada.

Complementando que, una trama es un componente, y así, cuando incrustado (propiedad de) en una forma, la forma sabe sobre él y el bastidor sabe acerca de la forma (puede utilizar sus métodos y propiedades. Un uno incorporado pueden también hacer eso, pero requiere codificación adicional)

Quizás Embarcadero podría darnos una mano mediante la creación de un TEmbeddableForm o una interfaz para tales fines

Regards, Alvaro Castiello