
Mejor respuesta Gronfi , 16 febrero 2019 - 05:26
Hola, quería cerrar este tema, con el tiempo hemos visto que el problema estaba en las DLLs de C++ y de como recogían y trataban los campos de tipo char*
Así pues, perro verde solucionado

Mejor respuesta Gronfi , 16 febrero 2019 - 05:26
Hola, quería cerrar este tema, con el tiempo hemos visto que el problema estaba en las DLLs de C++ y de como recogían y trataban los campos de tipo char*
Así pues, perro verde solucionado
Escrito 21 diciembre 2018 - 10:27
Hola,
a ver si le ha pasado a alguien algo similar.
Tengo una aplicación dividida en distintos componentes (funciones básicas, lógica de negocio,...), de manera que cada parte de esas es un package.
La aplicación funciona bien sin problemas.
Ha llegado el momento de integrar unas dlls implementadas en C++, integración que no tiene mayor problema...o eso creía
El problema viene al llamar a las funciones de las dlls que tienen como parámetro un objeto de tipo record que en el lado de C++ recoge una estuctura con campos similares.
Si tengo la aplicación en modo 'package' cuando hago las llamadas a esas funciones da un access violation como la copa de un pino en la dll 'msvcrt.dll', pero si construyo la aplicación en modo no package es decir añadiendo todas las unidades necesarias al proyecto y sin tocar una coma de código, esas llamadas se ejecutan bien. Me tiene loco.
¿Alguien sabe por donde pueden ir los tiros?
Escrito 21 diciembre 2018 - 03:24
Hola,
a ver si le ha pasado a alguien algo similar.
Tengo una aplicación dividida en distintos componentes (funciones básicas, lógica de negocio,...), de manera que cada parte de esas es un package.
La aplicación funciona bien sin problemas.
Ha llegado el momento de integrar unas dlls implementadas en C++, integración que no tiene mayor problema...o eso creía
El problema viene al llamar a las funciones de las dlls que tienen como parámetro un objeto de tipo record que en el lado de C++ recoge una estuctura con campos similares.
Si tengo la aplicación en modo 'package' cuando hago las llamadas a esas funciones da un access violation como la copa de un pino en la dll 'msvcrt.dll', pero si construyo la aplicación en modo no package es decir añadiendo todas las unidades necesarias al proyecto y sin tocar una coma de código, esas llamadas se ejecutan bien. Me tiene loco.
¿Alguien sabe por donde pueden ir los tiros?
Intersante lio, nunca lo he hecho y no tengo idea,
¿pero será que la llamada desde un package es diferente a una aplicación normal?
Saludos
Escrito 22 diciembre 2018 - 05:38
No creo que el tema vaya por cómo se organiza y compila el código. Seguro que hay un error en el mismo, los fantasmas no existen pero algun error arrastrado en cadena nos los recuerdan. Cuando se usa C/C++ desde Delphi hay que pensar que no son lenguajes equivalentes y que el paso de parámetros a funciones hay que interpretarlo bien para evitar sobresaltos.
Saludos.
Escrito 16 febrero 2019 - 05:26 Mejor respuesta
Hola, quería cerrar este tema, con el tiempo hemos visto que el problema estaba en las DLLs de C++ y de como recogían y trataban los campos de tipo char*
Así pues, perro verde solucionado
PROGRAMACIÓN →
API →
Ejecutar funciones de una DLL desde Delphi, Ingeniería inversaComenzado por genriquez , 10 mar 2020 ![]() |
|
![]()
|
||
PROGRAMACIÓN →
Lazarus / FreePascal →
Modificación a Bitmap en un dll genera ACCESS VIOLATIONComenzado por Ricardo Mostalac , 15 jul 2015 ![]() |
|
![]()
|