![]() |
Re: Fehler nach freigeben von DLL
Zitat:
|
Re: Fehler nach freigeben von DLL
nein weil ich dann nur noch delphi dlls unterstützen kann
ich will aber in dieser hinsicht unabhängig bleiben |
Re: Fehler nach freigeben von DLL
Hallo,
wenn du ShortString verwendest, geht es auch ohne sharemem. Heiko |
Re: Fehler nach freigeben von DLL
ich verwende nur PChar
|
Re: Fehler nach freigeben von DLL
*push*
|
Re: Fehler nach freigeben von DLL
Ich hab was neues heraus gefunden.
Durch // und viel testen :mrgreen: jetzt bin ich draufgekommen das in der Datenbank.dll eine Zeile drinnen ist wenn ich sie weg tuhe (mit //) dann gibt es beim beenden keinen fehler. und zwar:
Delphi-Quellcode:
so jetzt hab ich des auch mit
SetLength(DataArray^, mysql_num_fields(MySQL_myRes));
Delphi-Quellcode:
getestet das ich mysql als fehler ausschließen kann und siehe da an dieser Zeile scheitert es.
SetLength(DataArray^, 1);
ABER mein Problem ist die Frage warum, denn: -Es wird an dieser Stelle kein Fehler ausgelöst -SetLength(DataArray^, 0); funktioniert :wall: DatenArray ist vom Typ PDataArray.
Delphi-Quellcode:
Dieses Array ist in der Exe vorhanden und wird der DLL als Parameter übergeben
PDataArray = ^TDataArray;
TDataArray = array of PChar; Die Daten werden RICHTIG an die Anwendung geschickt. Aber beim beenden kommt dann der Fehler :wall: :gruebel: :wall: :gruebel: :wall: |
Re: Fehler nach freigeben von DLL
*push*
|
Re: Fehler nach freigeben von DLL
Hallo,
Ein SetLength erzeugt u.U. einen neuen Pointer (ReAlloc), wahrscheinlich ist der Pointer im Daten-Segment der Dll (?? lange her, das mit Dll bei mir). Warum machst du das SetLength nicht vor dem DLL-Aufruf ? Falls die Länge nicht bekannt ist, nimmt halt ne "grosse" Zahl. Heiko |
Re: Fehler nach freigeben von DLL
Zitat:
Ich versteh einfach nicht wieso :wall: Da gibt es ja eigentlich keinen Zusammenhang oder? Zitat:
eine große zahl nehmen ... ganz sicher nicht. den diese Anwendung soll schnell laufen und das ist eine überhaupt nicht saubere lösung |
Re: Fehler nach freigeben von DLL
Hallo,
Ein ReAlloc erzeugt unter Umständen einen neuen Pointer und der alte wird nicht mehr verwendet. Vielleicht solltest du bei der Übergabe ein Pointer auf einen PChar nehmen statt das PChar selber. Der Zusammenhang: Tja, Dlls. Mache mal zum Test ein SetLength vor DLL-Aufruf mit einem grösseren Werte also in der DLL gemacht wird. Dann verringert das DLL-SetLength den Speicher nur, ReAlloc sollte nicht aufgerufen werden. Zu "grosser Wert". In der DLL muss eh Speicher angefordert werden, wei viel hängt wovon ab ? Das man einer Funktion ein PChar + dessen Grösse übergeben muss ist doch nichts angewöhnliches. Wenn ich z.B. eine API-Funktion für Pfade benutzen will, nehme ich MAX_PATH als Grösse des PChar, obwohl ich vielleicht kleiner Pfade zurückbekomme. Heiko PS: MS (jaja, genau die) hatten mal in einer alten Word (2.0 für Dos) auch so nen ReAlloc-Fehler drin, der "ab- und zu" zum Absturz des Programms geführt hatte. Das stand mal in nem C-Buch bei ReAlloc drin. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:46 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz