Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Fehler nach freigeben von DLL (https://www.delphipraxis.net/90751-fehler-nach-freigeben-von-dll.html)

RavenIV 26. Apr 2007 16:27

Re: Fehler nach freigeben von DLL
 
Zitat:

Zitat von gsh
Ich weiß das man keine Strings verwenden sollte. Ich verwende auch ganz sicher keiner. hab sogar extra nochmal nachgeschaut

Bau trotzdem den sharemem ein. Es schadet ja nicht.

gsh 26. Apr 2007 16:40

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

hoika 26. Apr 2007 19:38

Re: Fehler nach freigeben von DLL
 
Hallo,

wenn du ShortString verwendest,
geht es auch ohne sharemem.


Heiko

gsh 26. Apr 2007 20:42

Re: Fehler nach freigeben von DLL
 
ich verwende nur PChar

gsh 27. Apr 2007 18:02

Re: Fehler nach freigeben von DLL
 
*push*

gsh 28. Apr 2007 11:24

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:
SetLength(DataArray^, mysql_num_fields(MySQL_myRes));
so jetzt hab ich des auch mit
Delphi-Quellcode:
SetLength(DataArray^, 1);
getestet das ich mysql als fehler ausschließen kann und siehe da an dieser Zeile scheitert es.

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:
PDataArray = ^TDataArray;
  TDataArray = array of PChar;
Dieses Array ist in der Exe vorhanden und wird der DLL als Parameter übergeben

Die Daten werden RICHTIG an die Anwendung geschickt. Aber beim beenden kommt dann der Fehler :wall: :gruebel: :wall: :gruebel: :wall:

gsh 29. Apr 2007 17:26

Re: Fehler nach freigeben von DLL
 
*push*

hoika 30. Apr 2007 07:24

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

gsh 30. Apr 2007 08:12

Re: Fehler nach freigeben von DLL
 
Zitat:

Zitat von hoika
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).

Der Pointer wird von der exe in die dll übergeben und die größe vom Array wird ja richtig gesetezt. Nur das Programm stürtzt aber nach dem freigeben der DLL ab.
Ich versteh einfach nicht wieso :wall: Da gibt es ja eigentlich keinen Zusammenhang oder?

Zitat:

Zitat von hoika
Warum machst du das SetLength nicht vor dem DLL-Aufruf ?
Falls die Länge nicht bekannt ist, nimmt halt ne "grosse" Zahl.

nein ist nicht bekannt.
eine große zahl nehmen ... ganz sicher nicht. den diese Anwendung soll schnell laufen und das ist eine überhaupt nicht saubere lösung

hoika 30. Apr 2007 08:19

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 12:44 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz