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

abajo

En las ventanas secundarias de la DLL no funcionan Encontrar ramas similares


ilysha   (2001-12-20 10:00) [0]

La situación es esta: se ha desarrollado un gran paquete de aplicaciones, que consta de las principales aplicaciones exe-module y DLL. Todo ha sido probado y depurado.
Ahora es el momento de personalizar la interfaz de usuario de acuerdo con el estándar de la industria, y de repente resultó que las teclas de acceso rápido del menú emergente no funcionan en ventanas secundarias MDI desde archivos DLL. Si llama a la ventana como una ventana SDI, entonces todo es excelente, pero no es adecuado como solución a este problema.
Empíricamente, resultó que todos los comandos son procesados ​​por la ventana principal de la aplicación.
Quien enfrentó este problema comparte experiencia en la solución.



Алексей Петров   (2001-12-20 10:05) [1]

Active la opción "Construir con paquetes de tiempo de ejecución" en todas partes; esto reducirá los requisitos de recursos y esto debería resolver el problema.

El problema es que exe y DLL tienen su propia aplicación separada. Además, son de diferentes tipos, porque TApplication en exe no es lo mismo que TApplication en DLL.



ilysha   (2001-12-20 10:53) [2]

Alexey, al asignar Application.Handle desde la aplicación principal a la biblioteca DLL, se resuelve el problema de la existencia de un Handle: aquí todo está en orden.



vedmed   (2001-12-20 10:54) [3]

Se recomienda establecer el identificador del objeto Aplicación en la DLL igual al identificador correspondiente del módulo ejecutable; para obtener más detalles, consulte la ayuda sobre TApplication.



Алексей Петров   (2001-12-20 11:16) [4]

La pregunta no es solo en Application.Handle. La interacción entre objetos en exe y dll ocurre en todos los frentes en su caso.

Cuando estudié cómo funciona toda esta cocina (objetos, paquetes, etc.), llegué a la conclusión: Usar un solo objeto en DLL y EXE es correcto solo cuando se usan paquetes de tiempo de ejecución. Si el siguiente ejemplo no es suficiente para confirmar esta declaración, escriba, intentaré justificar con más detalle.

Ejecute un experimento (sin paquetes):
inserte este procedimiento en la DLL y llame a exe con cualquier objeto como parámetro:

procedure isObject(obj: TObject);
begin
if obj is TObject then
ShowMessage("Is object")
else
ShowMessage("Is NOT object")
end;


El resultado, creo, te complacerá :)



Ura   (2001-12-20 12:21) [5]

Escucha, ¿tienes formularios MDI en una DLL?
Tal vez Delphia pueda establecer contacto con una aplicación MDI ...



ilysha   (2001-12-20 12:25) [6]

El resultado me mató, o más bien, dirá que él mató mi sistema. ¿Qué significa esto?
Y, sin embargo, Alexey, puedes aprender más sobre tu propia investigación.
Sobre nuestro proyecto -
Hay un módulo básico: pro.exe. Al inicio, verifica la presencia de módulos DLL y los carga con el comando LoadLibrary.
Desde cada módulo, se inicia el formulario mdi-child, con el que trabaja el usuario.



Алексей Петров   (2001-12-20 13:02) [7]

Acerca de mi investigación, mis manos nunca llegan a escribir un artículo :)

Brevemente, el significado es el siguiente:
Todos los objetos tienen una parte del sistema VMT. Para D5, esto es 76 bytes. Esta parte se utiliza principalmente para admitir RTTI. Entre otras cosas, el antepasado del objeto está registrado en él. Usando este campo, se crea una lista vinculada con la ayuda de la cual puede obtener de cualquier clase a través de todos los antepasados ​​a TObject. Es este campo el que utiliza la función TObject.ParentClass.

Todos los VMT, incluida la parte del sistema, se almacenan en el segmento de código de cada módulo (DLL, EXE, BPL).

Si paquetes de tiempo de ejecución no utiliza en cada módulo su TObject, sin saber nada de los demás. En consecuencia, las jerarquías de objetos en cada uno de los módulos no están conectadas de ninguna manera.

Cuando se utilizan paquetes de tiempo de ejecución, el TObject general se encuentra en el paquete vcl50.bpl y, en consecuencia, no hay problemas.

Aclararé la declaración: Es seguro usar una instancia en varios módulos solo si el objeto se describe en una BPL conectada a todos los módulos que usan el objeto.

Porque el código del sistema y las estructuras de datos del sistema, en exe y dll, si se compilan con una versión de Delphi, coinciden; a menudo estos problemas no aparecen y surgen solo en lugares raros, como el suyo, por ejemplo.

Para su información:
TApplication, TScreen, TForm y Co se describen en vcl50.bpl. En muchos casos, es suficiente conectar solo este paquete.

Cuando el sistema está casi listo, rehacer casi no tiene sentido, pero para el futuro:
Para sistemas como el suyo, para garantizar que las ventanas secundarias puedan acceder correctamente al MDIFrame, tiene sentido crear un paquete que contenga la ventana principal y un antepasado abstracto para todos los MDIChilds.
Al mismo tiempo, el exe-shnik se vuelve mínimo: descarga el paquete principal y listo.
Y cada uno de los paquetes con formularios MDIChild ya funciona audazmente con el formulario principal. Debido a la generalidad del código VCL, todo funciona como si todo estuviera en un exe-shnik.



ValeraVV   (2001-12-20 13:50) [8]

1. No se suponía que el resultado matara el sistema (a menos, por supuesto, lo que dijo Alexey Petrov ©)
2. El operador is compara dos punteros a una clase (aunque el primer puntero corre por la jerarquía), y si estos dos punteros coinciden, entonces podemos decir que obj es TObject. En consecuencia, cuando se llama a un método no virtual e inédito de un objeto, podemos decir con seguridad que la dirección del método se toma de la información generada por el compilador. Si el EXE principal y la DLL se compilan por separado, para ellos estos son métodos diferentes: el resultado no es predecible.
3. Aún así, en mi humilde opinión, VMT no se genera en la memoria para cada objeto creado (lo que significa TObject, no objeto), pero solo se da una referencia a la estructura general de la clase, luego el punto dos también es válido para métodos virtuales
4. Si no se utilizan paquetes, se crean variables globales en el contexto del hilo principal, pero en diferentes lugares.En los paquetes, cuando se usa threadvar, se usa un hilo para cada hilo, independientemente del módulo
5. El proceso de cambiar a paquetes no es tan complicado (marque y compile todos los proyectos) y ahorrará recursos si hay muchas DLL y, además, las ventanas VCL están integradas y la interacción se minimiza (de lo contrario, surgirían problemas) antes)
5. Si Microsoft crea un enorme directorio system32 y lo usa desde todos sus programas, además de hacer un tiempo de ejecución de VC crea DLL, y aún más para su VB, entonces ¿por qué no usamos BPL, donde no solo se importan procedimientos, sino también y se rastrea la información sobre las clases, su jerarquía, etc., entonces esto no es un signo negativo de Delphi (en el sentido de que ilysha tiene problemas con Popup ShortCut "s), sino un plus.

Todo lo que es más alto que mi investigación para Petrov, pero aún tiene poco que ver con el problema de ilysha, más precisamente el 50%, surge la confusión debido a la definición incorrecta de la clase de objeto de otro módulo, o debido a ventanas de handl "incorrectas / no especificadas (lo que se hace a través de la Aplicación, Propietario, Padre)



Алексей Петров   (2001-12-20 14:18) [9]

> ValeraVV © (20.12.01 13:50)
punto 3 - no en mi humilde opinión, pero un hecho :) VMT es generada por el compilador una copia para cada tipo de objeto descrito. Los primeros 4 bytes de la instancia de cualquier objeto contienen solo un puntero a este VMT

Pero el elemento 4: threadvar no depende de los paquetes de ninguna manera. Allí se utiliza un mecanismo de datos puramente TLS.



ValeraVV   (2001-12-20 14:20) [10]

Llegó tarde con los adornos, también son incorrectos, él mismo utilizó este método para complementos:
Creé la clase TPlugIn y TMainProgramm, describí todos los métodos como resumen virtual y utilicé esta unidad desde el proyecto principal y los módulos, donde reescribí sus métodos, ¡la unidad no se ejecutó en BPL y todo funcionó!
El problema al comenzar con VCL, por ejemplo, al insertar un control adicional en el formulario principal provocó un error No se puede asignar TFont a TFont.
En resumen, cuidemos la llama de la llama, pare



ilysha   (2001-12-21 09:00) [11]

Aclaro la situación: si hace que la ventana de la DLL sea normal y la llame desde el módulo principal, entonces todos los PopupMenu funcionan muy bien, pero nuestro paquete requiere que el MDI-child sea de la DLL.

Alexey, rehicimos todo el proyecto para "Construir con paquetes", sin embargo, el problema persistió e incluso apareció uno nuevo: el formulario principal no se puede minimizar. ¿Quizás tienes un ejemplo de tu trabajo por ahí?



ValeraVV   (2001-12-21 09:51) [12]

¡La esencia del problema no está en la DLL!
¡ShortCut "s en MDIChild no funciona sin DLL!
Lo intenté yo mismo en un proyecto simple.
1. Trabajar solo en ShowModal
2. No trabaje en Show incluso si no hay una relación MDIForm-MDIChild
Es decir, el problema es más amplio, ¡no funciona incluso en el caso 2!



ilysha   (2001-12-21 10:16) [13]

Bravo ValeraVV !!!! Viva !!! ¡Hurra!

Estoy tratando de averiguar por qué no funciona, excepto ShowModal. Después de todo, debe haber una explicación normal. Y esto no es una llama.



ValeraVV   (2001-12-21 10:17) [14]

Y MDIForm se minimiza normalmente (en mi proyecto, al menos)



ValeraVV   (2001-12-21 10:25) [15]

llama soy yo sobre mi mensaje> ValeraVV © (20.12.01 14:20)
> ValeraVV © (20.12.01 13: 50)
necesita cavar la función pública TCustomForm.ShowModal: Integer; virtual
hay "diez diferencias" de Mostrar + Activar (opción 1) o redirigir los mensajes necesarios (ventanas) a la lista MDIChilds (opción 2)




nikkie   (2001-12-21 10:37) [16]

poner en MDIChild ActionList - el trabajo de su acceso directo



ilysha   (2001-12-21 11:08) [17]

Gracias a todos los que no permanecieron indiferentes a este tema.

Además, expreso mi sincero agradecimiento a Alexei Petrov por su ejemplo, creado y enviado a nosotros como una herramienta de enseñanza. Ahora todo ha caído en su lugar y está funcionando.
Muchas gracias humanas.



ilysha   (2001-12-21 11:12) [18]

Se puede establecer un ejemplo en una dirección permanente:
http://www.ubb.adm.yar.ru/downloads/public/develop/delphi/mdi-BPL.zip
El archivo es propiedad de su autor - Alexei Petrov mailto: AKPetrov@pisem.net



ilysha   (2001-12-21 15:17) [19]

Gracias nikkie.



ValeraVV   (2001-12-21 17:10) [20]

En resumen,
en una forma no modal diferente de la principal
PopupMenu de acceso directo no funciona solo en Delphi5
(trabajo de ActionList de acceso directo)
en PopupMenu de acceso directo de Delphi6 funcionan bien, al igual que una ActionList en Delphi5




ilysha   (2001-12-22 13:35) [21]

Y saben, colegas, que después de publicar un enlace a un ejemplo de trabajo con MDI-Child en DLL de Alexey Petrov en mi servidor, a partir de las 13 horas del 22 de diciembre, se realizaron 2210 descargas.
¡Hurra!



ilysha   (2001-12-22 20:07) [22]

Cualquier persona interesada en el sitio web del Reino de Delfos en http://www.delphikingdom.com/helloworld/usesdll.htm Puedes leer algo en la DLL.



Páginas: 1 rama entera

Foro: "Principal";
Archivo actual: 2002.01.10;
Descargar: [xml.tar.bz2];

arriba





Memoria: 0.64 MB
Tiempo: 0.033 c
6-28513
atenuar
2001-10-15 02:19
2002.01.10
Código fuente http o cómo organizarlo ...


4-28555
Di_wind
2001-11-07 19:02
2002.01.10
proceso


4-28553
Eugene
2001-11-07 15:11
2002.01.10
¿Cómo restringir el acceso a los directorios a los usuarios?


4-28559
Beka
2001-11-09 00:39
2002.01.10
como cerrar el puntero dentro de la forma


3-28435
AlexNord
2001-12-10 06:08
2002.01.10
Batchmove





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 French
gallego georgiano Alemán Griego criollo haitiano Hebreo hindi Húngaro islandés Indonesian irlandés Italiano 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