2009-04-20 15 views
5

He visto que la mayoría de los componentes (VCL) en Delphi se dividen en dos partes.
1) designtime paquete
2) Tiempo de ejecución del paquete
Problemas con los paquetes de tiempo de ejecución y tiempo de diseño en Delphi

¿Por qué todo este alboroto. ¿Qué diferencia hay si los paquetes RunTime y DesignTime están unidos en un solo paquete?

Nunca he sido capaz de entender esta lógica de separación.

¿Cuál es la lógica detrás de esto?

Una vez que tuve la cabeza, alguien menciona que esta distinción se hizo solo para evitar adoptar y seguir los estándares de Component establecidos por Microsoft. Realmente no hay lógica detrás de esto.

¿Es esto cierto?

Respuesta

11

A. Algunos componentes tienen características de tiempo de diseño grandes y complejas, como los editores de propiedades, que es posible que no desee incluir en su aplicación en tiempo de ejecución.

B. Algunos proveedores de componentes no desean licenciar sus características de tiempo de diseño grandes y complejas para el uso en tiempo de ejecución libre de regalías, sino restringirlas a su uso por parte de los desarrolladores únicamente.

+0

Punto A: ¿Qué pasaría si digamos, por ejemplo, que los paquetes DesignTime y RunTime se incluyen en el EXE compilado? Estoy pidiendo esto como ahora. La memoria ya no es una restricción ya que casi siempre hay suficiente memoria disponible en un momento dado. Estoy de acuerdo con el punto B hasta cierto punto, pero para un buen programador será una tarea pequeña implementar una lógica que no permita la carga de la interfaz DesignTime durante RunTime. Esto siempre ha sido el caso con los componentes COM sin ningún problema. –

+2

Si utiliza unidades designtime o no se resuelve en tiempo compilado, no en tiempo de ejecución. Los paquetes son DLL enlazados estáticamente. Por lo tanto, el uso de paquetes hace que el ejecutable de destino dependa de ellos, es decir. Windows no podrá cargar y ejecutar el archivo ejecutable si no encuentra todas las dependencias. –

+0

No lo creo, porque si los paquetes están vinculados estáticamente, ¿dónde está la necesidad de encontrar todas las dependencias? –

4
  1. cosas designtime puede utilizar unidades/paquetes internos de Delphi a la que no tiene código fuente ni se legalmente autorizado para distribuir en forma binaria.
  2. Probablemente no desee hacer que su aplicación requiera que se instale Delphi en la computadora del usuario .

La lógica es mantener su propio código separado del código "pegamento" que lo hace agradable & fácil de usar en el IDE.

+0

Digamos, por ejemplo, si como escritor VCL de un control de cuadrícula, quiero darles a mis usuarios la posibilidad de realizar cambios en un diseño de cuadrícula, etc. en tiempo de ejecución, ya que podrían hacerlo en tiempo de diseño, entonces puedo hacerlo ¿esta? Después de todo, tengo que usar controles estándar proporcionados por CG y construir sobre ellos, o tengo que crear la IU desde cero por mi cuenta? –

+1

Sí, puedes hacer esto. Designtime se refiere a las bibliotecas utilizadas por Delphi IDE. Eso incluye editores de propiedades, asistentes de creación de códigos, en resumen, cualquier código que interactúe con el IDE. Por ejemplo, el editor de TStrings que puede usar en el IDE para editar la propiedad Items de TListBox es designtime. TListBox en sí mismo no. Si desea proporcionar un editor similar a sus usuarios para permitirles editar los elementos en tiempo de ejecución, debe proporcionar los suyos. –

5

Si se hubiera hecho un poco de investigación, usted habría encontrado hace this SO question pedido menos de 2 días ...

Como ya se ha explicado la razón principal es que no se puede incluir cualquier unidad de Delphi en un diseño paquete de tiempo de ejecución. Y no hay razón para hinchar su ejecutable con un código que solo puede ejecutarse dentro del IDE de todos modos.

+1

Esta debería ser la respuesta aceptada, a excepción del snark. :-) –

Cuestiones relacionadas