Casa
Top.Mail.Ru Yandeks.Metrika
Foro: "principiantes";
Archivo actual: 2008.02.03;
Descargar: [xml.tar.bz2];

abajo

Las ventanas midi de dll dan dirección Encontrar ramas similares


206196131 ©   (2008-01-06 22:31) [0]

en la DLL, tengo esencialmente un proyecto autosuficiente.
El conjunto y los nombres de las funciones que la forma primaria de las llamadas DLL están estrictamente definidas. ¿Cómo puedo hacer algo como la conexión dinámica de nuevos dlls con el código del proyecto principal, no yo?
Ahora algo como
var X1: TForm; comenzar FLib1: = LoadLibrary (PChar ("mdidll0.dll")); @InitPlugin1: = GetProcAddress (FLib1, PChar ("InitPlugin")); @DonePlugin1: = GetProcAddress (FLib1, PChar ("DonePlugin")); @CreateMDI1: = GetProcAddress (FLib1, PChar ("CreateMDI")); InitPlugin1 (entero (Aplicación), entero (Pantalla)); X1: = TForm (CreateMDI1); fin
utilizado para descargar el complemento



Leonid Troyanovsky ©   (2008-01-07 05:07) [1]


> 206196131 © (06.01.08 22: 31)

> en la DLL tengo esencialmente un proyecto autosuficiente.

http://www.podgoretsky.com/DM/BadTips.html#BT-03

Bueno, si él, deis-pero, autosuficiente, déjalo rundll32.exe

--
Saludos, LVT.



206196131 ©   (2008-01-07 22:02) [2]

http://www.podgoretsky.com/DM/BadTips.html#BT-03

¿Qué es lo que entendió completamente el tono?



Германн ©   (2008-01-07 22:08) [3]


> http://www.podgoretsky.com/DM/BadTips.html#BT-03
>
> ¿Qué es lo que entendió completamente el tono?
>

A un impulso obsesivo de meter formas en dll.



{RASkov} ©   (2008-01-07 22:21) [4]

> ¿Qué es lo que entendió completamente el tono?

> [3] Hermann © (07.01.08 22: 08)

Él solo leyó sin prestar atención :)



206196131 ©   (2008-01-07 22:48) [5]


> Al impulso obsesivo de abarrotar formas en dll


pero ¿por qué se te ocurrió la idea de que esto es malo?) discuta y ofrezca una alternativa.
para una situación en la que hay un proyecto que periódicamente debe complementarse con nuevas características pero al mismo tiempo no afecta lo que tiene



Sergey Masloff   (2008-01-07 23:01) [6]

206196131 © (07.01.08 22: 48) [5]
> y de dónde sacaste la idea de que esto es malo))
Esto es de conocimiento común. Como las alternativas. Por mil y cincuenta y una veces, es de alguna manera imposible discutir



Anatoly Podgoretsky ©   (2008-01-07 23:06) [7]

> 206196131 (07.01.2008 22: 48: 05) [5]

Y para ti una alternativa, ya lo has decidido todo.
Los creyentes para persuadir es inútil.



206196131 ©   (2008-01-07 23:08) [8]


> Mil cincuenta y una primera vez para discutir ya de alguna manera
> no tira


Bueno, como siempre grita) Aztoy, es conocido por todos los 100 hace años))

¿Por qué entonces este foro ... para obtener respuestas estúpidas a preguntas estúpidas,

cuando se requiere todo el goto para escribir el nombre de tres patas, lo que debe tenerse en cuenta.



Anatoly Podgoretsky ©   (2008-01-07 23:12) [9]

Atropellarás a otro lado



206196131 ©   (2008-01-07 23:12) [10]


> Pero, para ti, una alternativa, ya lo has decidido todo.
> Los creyentes para persuadir son inútiles.
>


No necesito una alternativa, solo necesito una dirección o una idea de cómo llamar a nuevos dlls previamente desconocidos para el proyecto principal



206196131 ©   (2008-01-07 23:16) [11]


> Te encontrarás con otro lugar


Esto no es una colisión, pero es una pena para nosotros sobre el foro cuando lo considero el recurso más autorizado para Delphi .....
y a cambio lo entiendo por mucho tiempo, todo se sabe ... y nada realmente en el tema



Loginov Dmitry ©   (2008-01-07 23:47) [12]

>> Al obsesivo deseo de meter formas en dll
>
>
> y de dónde sacaste la idea de que esto es malo)) argumenta
> y sugerir una alternativa.
> para una situación en la que hay un proyecto que se necesita periódicamente
> suplemento con nuevas funciones pero no afecta
> lo que tienes


Por lo tanto, en este foro se acepta: ¡los formularios en dll son malos! (esta creencia proviene, probablemente de [1]) :-D

De hecho, si compila todo con paquetes bpl, la diferencia entre exe y dll se borra por completo. Desafortunadamente, también hay oponentes al uso de paquetes ...

En general, necesitamos formularios en el archivo dll, ¡por favor! ¡Conecta los paquetes y listo!


> El conjunto y los nombres de las funciones que el formulario primario llama
> desde un archivo DLL está estrictamente definido. ¿Cómo puedo hacer eso?
> algo así como la conexión dinámica de nuevos dlls al mismo tiempo
> no soy el código del proyecto principal


Bueno, entonces un complemento ordinario! Busca en el directorio dado todos los dlls en los que están presentes las funciones dadas ... Luego, hace todo lo que necesita con ellos.



206196131 ©   (2008-01-08 01:46) [13]

Gracias Loginov Dmitry) lo que se necesita, solo que inicialmente miré desde el lado del arco. Y así, por la dirección del respeto



Германн ©   (2008-01-08 02:10) [14]


> 206196131 © (08.01.08 01: 46) [13]

Solo no te olvides de
> En general, necesitamos formularios en el dll-please! Enchufar paquetes
> y listo!

De lo contrario, dedicará todo su tiempo al tratamiento de las hemorroides.
O generalmente reemplace los paquetes dll. Esta es la opción más libre de hemorragias.
Aunque todos estos métodos son más o menos hemorroides debido a la dependencia de los paquetes de la versión Delphi. :(



Германн ©   (2008-01-08 02:15) [15]


> Aunque todos estos métodos son más o menos hemorroidales
> debido a la dependencia del paquete en la versión de Delphi. :(
>

Olvidé decir que esto se relaciona en muchos aspectos con
> Loginov Dmitry © (07.01.08 23: 47) [12]

Esto no es
> Entonces este foro aceptó
. Esta es la dura verdad de la vida. :(



Sergey Masloff   (2008-01-08 10:01) [16]

Loginov Dmitry © (07.01.08 23: 47) [12]
> De hecho, si compila todo con paquetes bpl, entonces la diferencia entre> exe y dll se borra por completo.
No borrar DLL es un estándar universal y utiliza la especificidad de Delphic en él: Moveton. Acerca de compilar con bpl: solo cura parte de los problemas. Digamos que, en una máquina de destino, el cliente tendrá su software instalado por un programador igualmente astuto cuyo Delphi es de la misma versión pero con un conjunto de paquetes de servicio diferente al suyo. Tenga el placer de ver que su aplicación deja de funcionar. Y después de reinstalar el suyo funciona y el "enemigo" no.
Luego resulta que necesita llevar todo bpl con cada aplicación, instalarlo en un directorio separado ... y así sucesivamente



Loginov Dmitry ©   (2008-01-08 10:15) [17]

> No borrado. DLL es un estándar universal y uso
> tiene una especificidad de Delphic-Moveton. Sobre compilar con
> bpl: cura solo una parte de los problemas. Digamos a la máquina objetivo
> el cliente instalará su software, por lo que algunos igualmente difíciles
> programador con Delphi de la misma versión pero con excelente
> de su conjunto de paquetes de servicio. Diviértete viendo
> cómo su aplicación deja de funcionar. Y luego de la reinstalación
> el tuyo funciona y el "enemigo" no.
> Entonces resulta que necesitas llevar todo bpl con cada aplicación
> instalar en un directorio separado ... y así sucesivamente


La buena noticia es que CodeGear no ha cambiado recientemente los paquetes de una versión a otra. Una aplicación escrita en Delphi2007 funciona muy bien con paquetes de Delphi2006 y Turbo Delphi 2006. Los problemas reales pueden ser con los paquetes de terceros instalados en System32: se puede compilar un paquete con el mismo nombre en cualquier versión de Delphi.



Sergey Masloff   (2008-01-08 10:26) [18]

Loginov Dmitry © (08.01.08 10: 15) [17]
Pues si es así. Y luego, antes entre paquetes de servicios, ni siquiera había compatibilidad.



Anatoly Podgoretsky ©   (2008-01-08 10:48) [19]

> Loginov Dmitry (08.01.2008 10: 15: 17) [17]

Entonces 2007: solo quería comerlo.



Leonid Troyanovsky ©   (2008-01-08 11:14) [20]


> 206196131 © (07.01.08 23: 16) [11]

> esto no es una colisión, sino una pena para nosotros sobre el foro

De hecho, incluso podrías pensar en ese consejo para usar
los formularios en el dll se recibieron en el foro local.

Es decir, quien le aconsejó esto, que responda otras preguntas.

Simplemente parece que [0] <> "cuando todo está listo".

--
Saludos, LVT.



Leonid Troyanovsky ©   (2008-01-08 11:19) [21]


> 206196131 © (07.01.08 22: 48) [5]

> y de dónde sacaste la idea de que esto es malo)) argumenta
> y sugerir una alternativa.


> 206196131 © (07.01.08 23: 12) [10]
>
Citado1 >> Pero, para ti, una alternativa, ya lo has decidido todo.
Citado1 >> Los creyentes para persuadir es inútil.

> No necesito una alternativa, solo necesito una dirección o una idea

Es decir, no es necesario.
Ortodoxo

--
Saludos, LVT.



Leonid Troyanovsky ©   (2008-01-08 11:25) [22]


> Loginov Dmitry © (07.01.08 23: 47) [12]

> Entonces, en este foro se acepta: ¡la forma en el dll es malvada! (viene
> esta creencia, probablemente de [1]) :-D

Esto no es una convicción, sino un conocimiento bastante práctico.
E incluso si viniera de mí, es solo porque
que me puse sobre los hombros de gigantes.

--
Saludos, LVT.



206196131 ©   (2008-01-08 16:31) [23]

Resulta que la campaña no está aquí sin ambigüedades ...

Comencé c dll ya que en ese momento era la única opción que imaginaba para la implementación del plan.

Como generalmente, se hacen todo tipo de platino y adiciones al software existente.
tal vez no estoy de pie



Anatoly Podgoretsky ©   (2008-01-08 16:55) [24]

> 206196131 (08.01.2008 16: 31: 23) [23]

Muy simple, según la documentación del autor.



206196131 ©   (2008-01-08 18:27) [25]


> Muy simple, de acuerdo con la documentación del autor.

y si yo mismo soy el autor, qué enfoque debería usar, pero no entre en el código del programa principal.
No necesito volver a armar toda la basura una vez que ya está compilada.
Solo necesita agregar funcionalmente nuevo a un proyecto existente de acuerdo con el principio
dio un nuevo dll hay nuevas características
dio un dll modificado hay cambios / actualizaciones

¿Y por qué no te gusta aquí nebylo argumentalmente nadie,
dar al menos un enlace a algo inteligible sobre el tema: formularios en una DLL en esta situación = MAL

Según tengo entendido, los Paquetes son completamente desconocidos para esta área, después del cambio, el plan necesita ser reensamblado.



Германн ©   (2008-01-08 18:57) [26]


> dio un nuevo dll hay nuevas características

Esto es poco probable

> Según tengo entendido, los paquetes son completamente desconocidos para esta área, planifique
> después del cambio, debe volver a recopilar el proyecto de noticias

Malentendido



206196131 ©   (2008-01-09 00:34) [27]

Argumentos de Hermann donde están los tuyos

>
citado1 >> dio un nuevo dll hay nuevas características
>
> Et improbable.


qué improbable es)))
hay una forma en dll
3 se lo está comiendo
y el botón xnumx
procedimiento TfrmMDI_dll.Button1Click (Remitente: TObject); comenzar edit3.Text: = inttostr (strtoint (edit2.Text) + strtoint (edit1.Text)) fin
la boca es una dll completamente diferente
procedimiento TfrmMDI_dll.Button1Click (Remitente: TObject); comenzar edit3.Text: = inttostr (strtoint (edit2.Text) * strtoint (edit1.Text)) fin
ahora nuestro programa puede multiplicarse
de lo que no tienes nueva funcionalidad)))))

____________________________________________________


Citado1 >> Según tengo entendido, los paquetes son completamente desconocidos para esta área, plan
citado1 >> después del cambio, debe volver a recopilar el proyecto de noticias
>
> No entendí bien.


hay tal libro
http://st1.risunok.net/29658/1.jpg

hay tal página en ella
http://st1.risunok.net/29659/2.jpg

en el que está claramente escrito en ruso en blanco
que al modificar el paquete de alguien, lo más probable es que tenga que volver a armar todo el proyecto.

Conclusión Voy a leer libros, tal vez no pueda esperar argumentos)))))))



sniknik ©   (2008-01-09 01:33) [28]

> tiene esa página
> http://st1.risunok.net/29659/2.jpg
donde está escrito sobre módulos (dcu), pero dijeron que estaban hablando de paquetes (bpl).
mira cuidadosamente lo que lees ...

aunque, en mi humilde opinión, ese dll, ese bpl no importa, ambos tienen sus problemas, y ambos no son necesarios para el dudoso placer de entregar / actualizar el programa en partes ...
el servicio de implementación / soporte es confuso y, como resultado, envían todo en un solo lote "por si acaso", y el tamaño de "todo" con los paquetes es mucho mayor que un solo ejecutable.
se trata de aplastar en aras de reducir las actualizaciones.
para complementos? ... ok, una buena razón. pero! Aquí, cuando miro al autor, escribe tanto el programa como el complemento, y la probabilidad de que alguien más agregue complementos adicionales tiende a cero, ¿así que creo?
luego escupe y muele, escribe "de una pieza" (es decir, exe)
y con tus "complementos" te confundirás cien veces y harás una pieza de guano del programa, y ​​probablemente no podrás escribir un segundo (complemento) sin un protocolo bien documentado (pasarán un mes o dos y eso es todo), y navegaste estas conduciendo? es decir dibujar un esquema de interacción allí, documento, etc. Aquí, eso es lo que pensé.



Германн ©   (2008-01-09 01:41) [29]


> ahora nuestro programa puede multiplicarse
> que no tienes nueva funcionalidad)))))
>

Esta no es tanto la nueva funcionalidad del programa en sí, sino la nueva funcionalidad del complemento. Aunque esto es ciertamente una ventaja.


> tiene esa página
> http://st1.risunok.net/29659/2.jpg
>
> en el que está claramente escrito en ruso en blanco
> que al modificar el paquete, lo más probable es que tenga que
> reensamblar todo el proyecto.
>
> Conclusión Voy a leer libros, tal vez no puedas esperar tus argumentos
>)))))))
>

Esto es correcto Leer libros Pero léalo detenidamente, entonces tal vez comprenderá la esencia del segundo párrafo de ese párrafo. Y, por cierto, comprenderá la diferencia entre dll y bpl (en el contexto de por qué empujar formularios en dll es malo, pero en bpl es absolutamente natural).



Германн ©   (2008-01-09 01:54) [30]


> 206196131 © (09.01.08 00: 34) [27]

Si Otro en mi humilde opinión. Estoy muy confundido por su comprensión del término "complemento". Parece que su programa que los usa es solo un maniquí. No hay nada en sí mismo, y si lo es, entonces no está conectado (o casi nada) con complementos. Entonces, ¿por qué estos complementos en forma de dll son mejores que los complementos en forma de exe, que se pueden llamar a través de CreateProcess?



206196131 ©   (2008-01-09 02:12) [31]

sniknik sobre BPL escribe lo mismo, si algo cambia radicalmente, entonces necesita volver a armar todo el proyecto ...

Sí, todo está en los estantes y todo está escrito (quién / dónde / por qué / por qué) la etapa pasada))

Proyecto especializado

En 1 exe no lo hago por las siguientes razones:
No todas las categorías de usuarios necesitan ciertas funciones (por razones de seguridad); no hay forma de hacer nada; no hay problema.
La seguridad de las aplicaciones locales es otra historia.

Además, la conveniencia de actualizar el complemento hasta donde puedo verlo
Realmente no quiero iniciar archivos exe 150


> sin un protocolo documentado

todo está estrictamente regulado, y los detalles del proyecto son tales que las bibliotecas son autosuficientes, no hay interacciones sabias entre los distintos módulos.

Todas las interacciones entre módulos están limitadas a una base de datos común.


> servicio de implementación / soporte

sobre este tema será necesario pensar con más detalle, el factor humano no se puede deshacer

sniknik gracias por los comentarios constructivos



206196131 ©   (2008-01-09 02:20) [32]

aunque ese 115 exe que 114 dll aquí solo practique mostrará cuál es más conveniente



206196131 ©   (2008-01-09 02:22) [33]

Aunque ese 115 exe que 114 dll aquí solo practica mostrará lo que es más conveniente
En esta etapa, hacer lo planeado con el dll no causa ningún problema, aparte de las pequeñas cosas de la vida.



sniknik ©   (2008-01-09 02:42) [34]

> sniknik sobre BPL escribe lo mismo, si algo cambia radicalmente, entonces necesita volver a armar todo el proyecto ...
en realidad no escribí eso ...
"reensamblar" no es necesario. generalmente ... pero generalmente envían todo de todos modos, en caso de que el cliente pierda / falle / una versión muy antigua /.../ en caso de que la secretaria tenga días críticos, y la clave de la caja fuerte con el kit de distribución es / solo por si acaso.
es decir en la práctica, en aras de lo que dividen el programa en paquetes: "conveniencia de actualización / menor tamaño de actualizaciones", en la práctica, NO FUNCIONA, por el contrario, empeora aún más. Aquí está lo que escribí.



206196131 ©   (2008-01-09 03:14) [35]

sniknik
Lo sé, comencé a escribirte y luego me distraje



Anatoly Podgoretsky ©   (2008-01-09 03:32) [36]

> sniknik (09.01.2008 02: 42: 34) [34]

La esencia de DLL es el uso de ellos por muchos programas, pero si solo hay un programa, entonces esta no es la esencia, sino una perversión. Todos los enlaces a una actualización parcial no resisten las críticas, habrá un infierno dll regular.
Además, la regla de usar DLL es el intercambio de solo tipos simples, sin clases y tipos complejos con una vida controlada, con Delphi la situación se agrava aún más por el hecho de que DLL tiene su propio RTTI y su propio administrador de memoria. Es por eso que BPL se inventó para eliminar estas deficiencias, al mismo tiempo, BPL es una DLL común que solo tiene en cuenta las realidades de Delphi.



Германн ©   (2008-01-09 04:05) [37]


> Anatoly Podgoretsky © (09.01.08 03: 32) [36]

Me perdí de nuevo. Shiknik lo sabe. :)
Lo siento Una vez más inmovilizado. ¡Pero esta es solo la segunda vez!
:)



206196131 ©   (2008-01-09 04:24) [38]


> La esencia de DLL en el uso de muchos programas, si
> un programa,


y si hay muchos programas para un turno, y solo hay una interfaz visual para acceder a ellos



Германн ©   (2008-01-09 04:56) [39]


> 06196131 © (09.01.08 04: 24) [38]

"Por el contrario" está escrito juntos. ¿Y cuándo comenzarás a leer libros?



sniknik ©   (2008-01-09 09:08) [40]

> Todos los enlaces a una actualización parcial no retienen el agua, habrá un infierno dll regular.
Eso es todo. probablemente solo para bpl, y desde el lado práctico.
solo un programa es de tal apoyo, no escrito por nuestro departamento, gracias a Dios, pero hay más problemas de él que de todos los demás combinados. o más bien con ella.
y no solo se trata de la "versión múltiple" de las partes, aunque es horrible, pero fácil de hacer con la actualización de todo lo que escribí. aquí también, porque La estructura del programa, según tengo entendido, resulta ser más confusa debido al principio modular total, lo que significa que la probabilidad de errores es mayor (lo cual es confirmado por la práctica), y generalmente hay situaciones idiotas, debido a los intentos de hacer que cada módulo (plug-in) sea más autónomo, sucedió que fue necesario registrar una configuración en tres lugares ... y Dios prohíbe cometer un error y prescribir diferentes valores.
en general, el proyecto comenzó como "¡increíble, qué programa genial tendremos! Todos los ladrillos que el cliente quiera se compondrán, ¡eso es todo! de hecho, resultó ser el programa más complicado y torpe, un cambio para un cliente en realidad "presupuesta" una nueva rama incompatible con el paralelo (es decir, todo es exactamente lo contrario de lo que quieres), porque deseos del cliente, por lo general son tan impredecibles ... no previstos por el protocolo de complemento creado hace dos años ... sino porque la estructura general es modular, luego un nuevo módulo con un nuevo protocolo (no se puede arreglar el antiguo para que otros no se "caigan" o rehagan todo) también cambia el "núcleo", etc. Realmente el infierno.
aunque en general el programa no es nada especial, fue fácil de escribir de la manera habitual (los complementos son claramente "descabellados" en aras de estos "beneficios", conveniencia, etc. que no funcionaron)

> y si hay muchos programas a la venta, solo hay una interfaz visual para acceder a ellos
intenta averiguarlo, tal vez puedas hacer eso ... (aunque hubiera hecho apuestas si hubiera alguna)



206196131 ©   (2008-01-09 14:56) [41]


> Sí, ¿y cuándo comenzarás a leer libros?

ya



206196131 ©   (2008-01-09 15:23) [42]

así que el tema del niño está cerrado
no tiene sentido continuar la conversación, ya que todos aprenden de su propio rastrillo))



Amoeba ©   (2008-01-09 16:43) [43]


> 206196131 © (09.01.08 15: 23) [42]
>
> entonces el tema del niño está cerrado
> no tiene sentido continuar la conversación, ya que todos aprenden
> en su rastrillo))
>

Ah, y habrá muchos rastrillos ...



206196131 ©   (2008-01-09 18:26) [44]


> Ah, y habrá muchos de estos rastrillos ...

No discuto, pero como no hay esencialmente ninguna otra propuesta, lo haré como lo veo por mí mismo.



Loginov Dmitry ©   (2008-01-09 21:34) [45]

> La esencia de DLL en el uso de muchos programas, si
> el programa es uno, entonces esta no es la esencia, sino una perversión. Todos los enlaces
> para actualizaciones parciales no resistas las críticas, será normal
> dll infierno.


Todos deberían tener una opinión sobre esto. Déjame expresar el mío.
Podemos hablar sobre el hecho de que dll es malo y todo eso es solo para los sistemas más primitivos, donde es completamente obvio que todo se puede hacer en un exe-shnik. Si el sistema es simple, estoy de acuerdo en que no tiene sentido dividir un montón de módulos. Si el sistema es complejo, pero desarrollado por una persona, ¡entonces probablemente no haya razón para descomponerlo (pero con un estiramiento)! Pero si el sistema es desarrollado por el equipo, y su complejidad es MUY alta, entonces NO hay posibilidad de implementar todo en un módulo. Es decir es posible, pero SOLO teóricamente. ¡No puedo saber absolutamente todo, y cada uno de los miembros del equipo tampoco lo sabe todo! Estoy haciendo un programa de acogida. Debería funcionar, digamos, con las teclas iButton. Pero es completamente paralelo a mí lo que es y no estoy interesado en cómo trabajar con ellos, además, ¡no hay tiempo para resolverlo! Pero estoy seguro de que cuando se aplica una clave al teclado de contacto, mi programa debe responder a esto: leer el código de la clave, escribir o leer datos de él. En consecuencia, alguien está asignado a trabajar con llaves. Una persona crea una biblioteca con tres funciones: leer un número de clave, escribir datos en una clave, leer datos de una clave. A continuación, el sistema se instala en el cliente. Si necesita modificar / arreglar la biblioteca, solo se está finalizando. Si necesita modificar la aplicación principal, solo se está finalizando. En consecuencia, el cliente solo actualiza la parte que necesita. No tiene sentido actualizar todo el sistema.
Más ... El sistema interactúa con el equipo. Por ejemplo, con un dispensador de combustible. Es necesario que el sistema siempre que sea posible funcione con todo tipo de dispensadores de combustible. Hay muchos de ellos. Decir 20 - 30 pcs. Cada tipo de dispensador de combustible tiene su propio protocolo de intercambio. Los protocolos cambian constantemente y se finalizan; esto debe ser monitoreado y enmendado de manera oportuna. La única forma razonable de interactuar con el dispensador de combustible es escribir conductores individuales. Resulta pequeños dlls de hasta 50 KB de tamaño. Déjalos piezas 20. Pero trabajar con ellos en tiempos 20 es más fácil que si todos estuvieran ubicados en un módulo. El cliente compra un nuevo dispensador para sí mismo: los cambios necesarios se realizan en un solo archivo y solo su cliente se actualiza. Por cierto, este fue un ejemplo cuando la división en módulos ayuda incluso si solo una persona trabaja en el sistema, y ​​es cierto no solo para los dispensadores de combustible, sino también para otros equipos (mesas de efectivo, terminales de pago, pantallas de clientes, etc.). Para mezclar trabajo con diferentes equipos en un módulo: ESTO ES UNA PERFECCIÓN.

Entonces, la única regla por la cual se toma una decisión sobre el desglose en módulos es la conveniencia del mantenimiento más completo del sistema. Si el significado del desglose es ENTENDIDO claramente, entonces no debe abordar este asunto; de todos modos, NO HABRÁ SENTIDO. Si hay un sentido y se realiza, es necesario romper. Todos los módulos deben ser compatibles en todo momento mientras el sistema está en funcionamiento. Es decir actualizar cualquier módulo sin actualizar el resto de los módulos no debería afectar el rendimiento del sistema. Las actualizaciones deberían mejorar el rendimiento del sistema, pero no empeorar de ninguna manera. Para hacer esto, necesitas tener ciertas habilidades. Si la finalización del módulo lleva a la actualización de todos los módulos del sistema (y así cada vez), esto indica que la persona no tiene suficiente experiencia para desarrollar un sistema de múltiples módulos, y es realmente mejor hacer todo en un módulo. Cuando trabaje con complementos, debe implementar completamente el intercambio de datos entre módulos. CADA biblioteca SE REQUIERE para poder devolver un número de versión (preferiblemente un número entero). Incluso si las capacidades de la biblioteca ahora están determinadas de manera única por el conjunto de procedimientos exportados, tarde o temprano, el número de versión seguirá siendo necesario. La aplicación de host también debe proporcionar un número de versión a cualquier biblioteca. Si se agregan nuevas funciones al módulo, se debe aumentar el número de versión, y antes de usar estas nuevas funciones, se debe solicitar el número de versión del módulo; esto determina si esta función está incluida en el módulo o no. Esta es la única forma de evitar el efecto mencionado en [34], es decir la necesidad de actualizar todo el sistema al actualizar alguna parte del mismo.



sniknik ©   (2008-01-09 22:58) [46]

Borrado por el moderador
Nota: doble



sniknik ©   (2008-01-09 22:59) [47]

Loginov Dmitry © (09.01.08 21: 34) [45]
y no notas la diferencia? de sus ejemplos y la empresa del autor (por una tecnología similar, que "me molesta")

ambos ejemplos son controladores que funcionan con dispositivos, es decir exactamente para qué sirven los dlls. en todas partes (el primero está un poco "borroso", probablemente no es un dll allí, es necesario, pero el servidor + los programas 2 del cliente. ya que las puertas probablemente se eliminan de la computadora principal, y además no solo. Y luego describí el protocolo por el cual los clientes envían la información al servidor e incluso si cada tipo de puerta está escrita por un cliente separado, la correa respetaría el protocolo de intercambio).

el autor está tratando de romper el programa, cuyo estado natural es "completo" (no, por supuesto, las personas hacen excepciones, pero no de una buena vida, sobre algún tipo de restricciones ...) en "ladrillos", es decir el formulario está allí, el formulario en sí, uno con uno procesando el otro con el otro, y necesita interactuar ... y la base es una (y las conexiones con autonomía? un montón), un montón de dll-ek doblado, con un "inicio" = programa común. y el programa no tiene la posibilidad, por ejemplo, de menú "zadizeyblit / razizeyblit" cuando llama / cierra un formulario tan autónomo, aparecen mensajes entre dichos módulos (ya que inicialmente en esos procedimientos 2-3 necesarios en el dll, nadie pone esta información / oportunidad ), y dado que el principio está cambiando, entonces la parte de la cabeza está cambiando, y tal vez los módulos antiguos y listos ... y comenzó. Los problemas y la dificultad comienzan a crecer como una bola de nieve. y en cosas que están en la primaria "original".

da el mismo ejemplo (del tipo del autor), solo adecuado "en la caja y sin problemas", de lo contrario, infundes en el autor falsas esperanzas de que "hizo todo bien" ...



Loginov Dmitry ©   (2008-01-10 07:58) [48]

> ambos ejemplos son controladores que funcionan con dispositivos,
> es decir exactamente para qué sirven los dlls. en todas partes


Todos estos dispositivos funcionan a través del puerto COM, por lo que si realmente lo desea, puede cargar todo en un módulo (estos módulos son los "controladores" para el sistema, no para Windows).


> el primero está un poco "engrasado", probablemente no haya un dll, es necesario, pero los programas 2
> servidor + cliente. porque las puertas probablemente se quiten del principal
> computadora, y tampoco solo. y aquí describió el protocolo para
> a qué clientes envían la información al servidor y dejan al menos cada tipo
> la puerta que escribe el cliente individual, privaría al protocolo
> intercambio observado


¿Y de dónde sale la puerta? :) ¿iButton solo necesita abrir la puerta? :)


> dar el mismo ejemplo (tipo de autor), solo adecuado
> "en la taquilla y no hay problema", de lo contrario infundes falsas esperanzas en el autor
> el hecho de que "hizo todo bien" ...


No inspiro ninguna esperanza "falsa". Espero que el autor entienda esto del último párrafo [45], y de nuestra discusión concluirá por sí mismo si vale la pena pasar tiempo en tales particiones.

En cuanto a los ejemplos adecuados: ya se ha dicho sobre los controladores; en el caso de un desarrollador, dividir en módulos hace la vida mucho más fácil. En el caso del desarrollo del equipo, cada uno implementa su parte como un módulo separado, esto es bastante conveniente y muy efectivo.



sniknik ©   (2008-01-10 09:14) [49]

> ¿Y de dónde viene la puerta? :) ¿iButton solo necesita abrir la puerta? :)
y no estás hablando de un sistema que tenemos en la entrada, adjuntamos una tarjeta electrónica y la puerta se abrió. en un caso, en otro, el torniquete estaba desbloqueado. pero al mismo tiempo tuvo en cuenta quién fue a dónde.
no? Bueno, no importa, el principio no sufre de esto, es un controlador de dispositivo.

> En cuanto a ejemplos adecuados ...
es decir Según tengo entendido, no tiene ejemplos adecuados de dividir un programa en dll (no controladores, no un código / recursos comunes, que por principio es independiente, es decir, partes de la interfaz, "por derechos de autor"). Algunas frases comunes sobre conveniencia y eficiencia. confirmación que tomas del "área" incorrecta.
es decir usted dice "el vehículo es conveniente y eficiente para los viajes", es cierto, pero lo aplica por alguna razón a los tractores de oruga, que no están destinados al transporte (ellos mismos lo transportan), sino al trabajo duro, como arar la tierra, planificar el terreno. Por supuesto, te refieres a autobuses y automóviles (y también hablas de ellos en los ejemplos), pero la sucursal es "sobre tractores" que intentan usarlos para el transporte (puedes hacerlo. Incluso hay situaciones en las que alguien se ve obligado a hacerlo. Pero en este caso no se habla de conveniencia y eficiencia cuenta).
Espero que la analogía sea clara.



206196131 ©   (2008-01-10 21:14) [50]

> En cuanto a ejemplos adecuados ...

1C de lo que no eres un ejemplo adecuado, aunque no hay una DLL, pero la idea es solo desde aquí



sniknik ©   (2008-01-11 01:34) [51]

> 1C que para usted no es un ejemplo adecuado, aunque no hay DLL
Correctamente, no dll sino ActivX (COM), que es exactamente para eso.

> pero aun así la idea es solo de aquí
tome de allí el método de implementación, y usted también será adecuado.



Германн ©   (2008-01-11 01:53) [52]


> sniknik © (11.01.08 01: 34) [51]

+1

Este es el camino a Loginov Dmitry © (09.01.08 21: 34) [45]
aplica. Aunque en su caso no existe una diferencia particular, a diferencia del caso del autor del tema.



206196131 ©   (2008-01-11 17:54) [53]


> sniknik © (11.01.08 01: 34) [51]


m por qué surgieron estas tecnologías ahora)))


> aplica. Aunque no hay mucha diferencia en su caso,
> a diferencia del caso del autor del tema.
>

Esto es lo que tu



sniknik ©   (2008-01-11 19:30) [54]

> m por qué surgieron estas tecnologías ahora)))
el teletransportador se rompió porque.

y, por cierto, si está interesado en mi opinión (que no está clara en todo), tendrá problemas incluso con estas tecnologías "básicas para esto", y su interfaz "ladrillos" recibirá muchas características nuevas, como incrustar el programa "independiente del idioma", incluso en formularios web, etc. donde puedes encontrar en general (como las mismas hojas de Excel ...), pero al mismo tiempo descartas las hemorroides con la escritura "no te metas".
no VCL, no VCL.
En mi humilde opinión, será más fácil escribir 10 del mismo tipo de programas de "copia al carbón" que un solo ActivX. (Tal vez revisé la cantidad, pero creo que el significado general es claro)



Páginas: 1 2 rama entera

Foro: "principiantes";
Archivo actual: 2008.02.03;
Descargar: [xml.tar.bz2];

arriba









Memoria: 0.86 MB
Tiempo: 0.108 c
2-1199966099
E
2008-01-10 14:54
2008.02.03
Ejecute el archivo EXE desde Main sin recurrir al corte y sin ..


15-1199134826
Ega23
2008-01-01 00:00
2008.02.03
Feliz año nuevo !!!!


2-1199445724
FIL-23
2008-01-04 14:22
2008.02.03
leer la hoja de Excel


2-1200053220
Yasha
2008-01-11 15:07
2008.02.03
Aplicación de formulario de Windows en RAD 2007


2-1199890935
andreil
2008-01-09 18:02
2008.02.03
Trabajando con un archivo en C ++





africaans albanés Arabic armenio Azerbaiyán vasco Bielorruso Bulgarian Catalán Chino (simplificado) Chino (tradicional) Croata Checo Danés Dutch Inglés Estonia filipina Finnish Francés
gallego georgiano Alemán Griego criollo haitiano Hebreo hindi Húngaro islandés Indonesian irlandés Italiana Japonés Korean letón lituano macedonio Malay maltés Noruego
persa polaco Portuguese Rumano Ruso Serbio Slovak Esloveno Español swahili Sueco Thai turco ucranio Urdu vietnamita galés yídish bengalí bosnio
cebuano esperanto gujarati hausa hmong igbo javanés kannada khmer lao latín maorí marathi mongol nepali punjabi somalí Tamil telugu yoruba
zulú
Английский Francés Alemán Italiano portugués Русский Español