2012-03-24 18 views
10

Estoy intentando crear un paquete para un componente personalizado que he creado. Se basa en varias bibliotecas, incluidas Graphics32, GraphicEx y CCR.Exif.Infierno de dependencia de componente personalizado

creé un proyecto paquete, escribió la unidad incluyendo su procedimiento de Registro, añadido algunas referencias adicionales Delphi me notificó a la requiere sección (incluyendo dbrtl.dcp, inet.dcp, soaprtl.dcp, vclimg. dcp, xmlrtl.dcp y dclGraphicEx140.dcp) y agregó muchas unidades al que contiene la sección para evitar advertencias al respecto implícitamente. El proyecto se compila y se puede instalar y usar en mi propia máquina sin problemas. Sin embargo, cuando quiero instalarlo en otra máquina, comienzan los problemas. Al final, tuve que copiar sobre todas las DCU de todos los componentes de terceros que utilicé, más los DCP y BPL de GraphicEx, que incluso tuve que instalar.

Suministrar una gran cantidad de archivos es un fastidio, pero a la vez superable, pero tener que instalar otros paquetes también es inútil. Podría deshacerme de ese DCP y BPL poniendo más unidades en el que contiene la sección, pero eso dio como resultado mensajes de error en mi propia máquina donde GraphicEx está realmente instalado. Esto es confuso para mí, porque con Graphics32 nada de eso ocurre ...

De todos modos, ¿cómo puedo mantener mi distribución al mínimo y evitar tales situaciones? Quiero que otros desarrolladores de mi equipo puedan usar el paquete sin preocuparse por lo que usé para construirlo. Para empezar, ¿no se pueden compilar todas las unidades de terceros en mi propia DCU?

+7

La instalación de los componentes es una lástima de Delphi, constantemente ignorada Embarcadero. – kludg

+0

¿Qué tipo de distribución está usted haciendo, a los usuarios de aplicaciones compiladas u otros desarrolladores para que los utilicen en el IDE? – afrazier

+0

@afrazier Paquetes con controles para que otros desarrolladores (miembros del equipo) los utilicen. –

Respuesta

0

Resumen

no pueden hacer uso de Delphi por un tiempo, pero lo hizo desarrollar mis controles visuales personalizados (Última versión que el trabajo era Delphi 6).

Hay dos problemas cuando se trata de dependencias de paquetes. Uno está instalando en el entorno Delphi, haciendo que los controles aparezcan en la paleta de componentes, más editores de componentes editores de propiedades &.

Y otra cuando se distribuyen los paquetes compilados en las máquinas de los clientes.

También depende de qué versión de Delphi esté ejecutando.

Diseño Tiempo

Al desarrollar un paquete personalizado, hay una pestaña de opciones de paquetes, que indica las carpetas de destino.

Los manuales generalmente le dicen a los desarrolladores que dejen vacíos esos cuadros de texto. Eso a veces funciona, a veces no funciona. Escribo explícitamente cada ruta de carpeta, en el respectivo cuadro de texto.

Hay una ruta de cuadro de texto para los archivos ".dcp", otra para " .dcu", y así sucesivamente.

Si tiene controles visuales y cosas como editores de propiedades o editores de componentes, es mejor dividir el código en 2 paquetes ("Runtime" & "Designtime").

Normalmente pongo los proyectos delphi (packages) fuera de la carpeta de instalación delphi.

tiempo de ejecución

Por lo general, la forma más rápida es poner el "*" ".bpl archivos de Windows (32) carpeta del sistema,/o similares "" .dcp carpeta Windows DLL".


Paquetes estructura de carpetas código fuente de sugerencias

con paquetes puede ser difícil. No sé cuánto ha cambiado el proceso de instalación con Embarcadero y las versiones más recientes de Delphi. El siguiente cuadro es un ejemplo de cómo organizar el código fuente. Espero eso ayude.

[-]--+--c: 
.....| 
.....+--[-]--+--software 
.............| 
.............+--[+]-----java 
.............| 
.............+--[+]-----php 
.............| 
.............+--[-]--+--delphi (not the delphi folder in program files) 
.....................| 
.....................+--[+]-----apps (source code for delphi programs) 
.....................| 
.....................+--[+]-----other 
.....................| 
.....................+--[-]--+--packages (all delphi packages source code here) 
.............................| 
.............................+--[+]-----lib (a single package for non visual controls, libraries) 
.............................| 
.............................+--[+]-----tools (package pair for non visual tcomponent descendants) 
.............................| 
.............................+--[+]-----json (example) 
.............................| 
.............................+--[+]-----xml (example) 
.............................| 
.............................+--[-]--+--mycontrols (folder custom visual controls) 
.............................|.......| 
.............................|.......+--[-]--+--delphi40 (folder for delphi40 version of "mycontrols") 
.............................|.......|.......| 
.............................|.......|.......+----------dsgvclctrls40.dpk (design-time package "mycontrols") 
.............................|.......|.......| 
.............................|.......|.......+----------runvclctrls40.dpk (run-time package "mycontrols") 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--demos (individual example for each "mycontrol") 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--design ("*.pas" component editors destination folder) 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--sources ("*.pas" source code destination folder) 
.............................|.......|.......| 
.............................|.......|.......+--[+]--+--bin ("*.dcu" destination folder) 
.............................|.......|........ 
.............................|.......+--[+]--+--delphi50 (folder for delphi50 version of "mycontrols") 
.............................|.......|........ 
.............................|.......+--[+]--+--delphi60 (folder for delphi60 version of "mycontrols") 
.............................|.......|........ 
.............................|.......+--[+]--+--delphi70 (folder for delphi70 version of "mycontrols") 
.............................|................ 
.............................+--[-]-----etc... 

aplausos.

+3

Lo siento, pero no veo cómo responde mi pregunta sobre cómo escribir y/o distribuir un componente de tal manera que el usuario (un desarrollador) no tenga que tomar medidas especiales (descargar/instalar dependencias, organizar su proyecto) de una manera específica) para usarlo. –

+0

El "Tiempo de diseño" es una especie de paso previo a su objetivo. El "tiempo de ejecución" está más dirigido a la distribución. – umlcat

0

Thijs, simplemente no puedes hacer eso con solo un paquete. El desarrollador objetivo requerirá casi todo lo que haya agregado al paquete. Pero hay una forma alternativa de hacer lo que desee: cree un archivo DLL con todos los componentes/bibliotecas que está utilizando en su propio componente y envuelva todos esos componentes/bibliotecas externos en algún código que exportará de la DLL. Luego crea tu componente sin usar los componentes externos directamente, sino la DLL que has creado. No puede en su componente "usar" ninguna unidad de los otros componentes externos/Bibliotecas. Tienes que construir una nueva unidad con todos los tipos de datos y la declaración requerida para todo lo que exportas de tu DLL. Todo esto funciona perfectamente, pero rápidamente se volverá muy complejo para una gran cantidad de componentes externos o bibliotecas.

+0

En lugar de una DLL, ¿podría usar un BPL para poder usar objetos? ¿Y no es posible compilar un BPL en el exe? –

2

Lo que experimentas es algo habitual para los que escriben componentes. La distribución es siempre así. Los paquetes no incluyen otros paquetes, en caso de que los mencionen. Está en su naturaleza.

Para superar una situación así, siempre trato mis componentes de la misma manera que si fueran un producto para vender: construyo un asistente de configuración que distribuye y registra todo lo que necesita el paquete.

En mi caso, InnoSetup funciona muy bien (http://www.jrsoftware.org/isinfo.php).

+0

¿Cómo verifica si un paquete no está ya instalado (ya que no puede tenerlo dos veces)? No hay un lugar fijo donde esperarlo. –

+0

@ThijsvanDien: todos los paquetes registrados con el IDE se enumeran en el Registro de Windows en 'HKEY_CURRENT_USER \ Software \ Embarcadero \ BDS \ 7.0 \ Known Packages'. La versión de BDS depende de la versión de Delphi. Si no me equivoco, 7.0 significa Delphi 2010. Eche un vistazo a los elementos debajo de esa clave para determinar si un cierto paquete ya está presente en el IDE. – AlexSC

0

Creo que AlexSC tiene la mejor respuesta, pero creo que podría haber una alternativa si ansolutely debe tener un componente personalizado que no tenga dependencias.

Me encontré con las frustraciones de dependencia de Delphi hace un tiempo tratando de crear un componente interno para nuestros desarrolladores. Mi sugerencia:

  1. desinstalar todas las dependencias de su componente utiliza

  2. En su paquete de componentes, extraiga el DCP encima de la sección de su paquete requiere.

  3. Copiar los archivos de origen de sus dependencias a sus componentes

Al distribuir el componente, que tendrá que distribuirán con el código de los dependecies requeridos

Usted se quedará en cuestiones si desea utilizar las dependencias por separado ya que Delphi no le permitirá tener nombres de unidades duplicados en los paquetes instalados.

Además, la razón por la que no desea utilizar DCU es el hecho de que las DCU se compilan para una plataforma y un compilador específicos. Por lo tanto, a menos que esté seguro de que todos los devolpers están en el mismo anuncio de plataforma usando la misma versión de Delphi, el código de dependencia necesita ser recompilado.

Una vez más, AlexSC tiene la mejor respuesta e InnoStudio es una gran pequeña herramienta.

Cuestiones relacionadas