Strings in DLL (keine Übergabe)

[tofse]

Hallo,

ich erstelle gerade die ersten DLL's und habe auch einiges darüber gelesen. Was mich nun aber doch verunsichert und wozu ist noch keine Antwort gefunden habe. Das Problem bei der Übergabe von Strings an Funktionen in DLL's habe ich verstanden und auch entsprechend umgesetzt. Aber wie sieht es aus, wenn ich strings innerhalb einer DLL Funktion verwende ? Irritiert hat mich u.a. dieser Satz "LongString wird dynamisch im Speicher alloziert. Natürlich im Speicher-manager der DLL und NICHT der Anwendung...."

Deshalb einfach nochmal die Rückfrage, ob ich Strings in DLLs einfach so verwenden kann, ohne ShareMem oder so zu benutzen? Und wie gesagt, es geht nicht um die Übergabe von Strings

Danke
Christof

[DeddyH]

Du meinst, nur intern innerhalb der DLL? Ich wüsste nicht, was dagegenspricht.

[tofse]

Na gut :-)
War v.a. durch den Beitrag verunsichert, geht da zwar um TStringList, aber es heisst dort auch, dass der Speicher für den String dynamisch im Speichermanager der DLL alloziert wird, und da dachte ich mir, dass es evtl. auch Probleme gibt, wenn ich in der DLL einfach so Strings verwende.

Christof

[DeddyH]

Da ging es aber um eine TStringlist als Übergabeparamater. Wenn die DLL auf Daten zugreift, die in ihrem eigenen Speichermanager vorhanden sind, was soll da anderes passieren als in einer Anwendung?

[himitsu]

DLL und EXE sind im Grunde erstmal beises ganz normale Executables.

Alles was du innerhalb der EXE machen kannst, kannst du auch innerhalb der DLL machen.


OK, mit der VCL muß man aufpassen, denn die DLL wird ja im Thread der EXE geladen, würde somit auch im Thread der EXE starten.
Aber wenn man 2 "getrennte" VCLs im selben Thread laufen läßt, dann kommen sie sich schnell in die Quere und Probleme sind vorprogrammiert.
PS: Die VCL arbeitet über Messages und wenn bei VCLs im selben Threadcontext arbeiten, landen unweigerlich Messages in der "falschen" Messageloop der anderen VCL-Instanz und damit würde die falsche Instanz nun die Messages verarbeiten.


Solange aber Strings und Objekte nicht die Grenze zwischen DLL und EXE über queren, gibt es keinerlei Probleme.
Man kann den String problemlos in einen PChar casten und bergeben ... in diesem Fall wird die Speicherverwaltung übergangen und somit kommt nicht der falsche Speichermanager, bzw. die String-Speicherwaltung, nicht mit einem ihr nicht gehörenden Sring in Berührung.

[hoika]

Hallo,

nimm einfach WideString statt String/UnicodeString,
dann kannst du sogar Strings aus der DLL
aus der Exe zurückgeben.


Heiko

[tofse]

Danke für die ausführliche Antwort. Jetzt ist einiges klarer

Zitat:

Zitat von himitsu (Beitrag 1142617)

DLL und EXE sind im Grunde erstmal beises ganz normale Executables.

Alles was du innerhalb der EXE machen kannst, kannst du auch innerhalb der DLL machen.


OK, mit der VCL muß man aufpassen, denn die DLL wird ja im Thread der EXE geladen, würde somit auch im Thread der EXE starten.
Aber wenn man 2 "getrennte" VCLs im selben Thread laufen läßt, dann kommen sie sich schnell in die Quere und Probleme sind vorprogrammiert.
PS: Die VCL arbeitet über Messages und wenn bei VCLs im selben Threadcontext arbeiten, landen unweigerlich Messages in der "falschen" Messageloop der anderen VCL-Instanz und damit würde die falsche Instanz nun die Messages verarbeiten.


Solange aber Strings und Objekte nicht die Grenze zwischen DLL und EXE über queren, gibt es keinerlei Probleme.
Man kann den String problemlos in einen PChar casten und bergeben ... in diesem Fall wird die Speicherverwaltung übergangen und somit kommt nicht der falsche Speichermanager, bzw. die String-Speicherwaltung, nicht mit einem ihr nicht gehörenden Sring in Berührung.

[angos]

Hi,

@Himitsu: D.h. Wenn ich in der Exe eine VCL-basierte GUI benutze und in der DLL ebenfalls, dann bekomme ich dadurch Probleme beim Ausführen?
Hast du dazu noch weitere Infos/Links?

Gruß

[Bummi]

@angos


versuch es einfach mal, ein Formular in der DLL mit ein paar Komponenten, üblicherweise kommt beim Laden schon die Meldung das bestimmte Klassen bereits registriert sind.
Wenn Du so etwas machen möchtest musst Du beide (DLL,EXE) mit Laufzeitpackages erzeugen ....

[Bernhard Geyer]

Zitat:

Zitat von Bummi (Beitrag 1142653)

versuch es einfach mal, ein Formular in der DLL mit ein paar Komponenten, üblicherweise kommt beim Laden schon die Meldung das bestimmte Klassen bereits registriert sind.

Dann bekommen wir seit 10 Jahren für unsere Hauptanwendung mit Pluginkonzept genau diese übliche Fehlermeldung nicht :-)
Solange du keine lebende Objekte zwischen Exe und Dll tauschen willst ist das keine Problem.

[Luckie]

Also dass man kein VCL Formular in eine DLL packen sollte, ist mir auch neu. Es gibt unzählige DLLs die Formulare beinhalten. Wie Bernhard schon gesagt hat, sind Plugin DLLs solche Kandidaten.

[angos]

Hallo,

Luckies und Bernhards Erfahrungen decken sich mit den meinen. Ich habe damit bis jetzt auch kein Problem gehabt und nutzen dieses Vorgehen eigentlich durchgehend.
Das beruhigt mich zumindest etwas.
Trotzdem hätte ich gerne gewusst, wir ihr darauf kommt, dass das problematisch ist.


Gruß

[Luckie]

Mal eben schnell zusammengetippt: FormInDLL.zip

Hier noch mal, zum gleich angucken: http://michael-puff.de/Programmierun...ormInDLL.shtml

[Bummi]

Ich muss meine Aussage einschränken, das Problem betrifft nur Komponenten welche RegisterClass verwenden. Derartige hatte ich wohl seinerzeit bei der Erstellung einer größeren Pluginlösung im Einsatz.

[himitsu]

Zitat:

Zitat von Bummi (Beitrag 1142699)

Komponenten welche RegisterClass verwenden.

Ich glaub (bin mir fast sicher, aber nicht nochma nachgeguckt) schon die TForm macht sowas, aber könnte sein, daß dort die VCL-Instanz im Namen mit eingebaut wird.

[Bernhard Geyer]

Zitat:

Zitat von Bummi (Beitrag 1142699)

Ich muss meine Aussage einschränken, das Problem betrifft nur Komponenten welche RegisterClass verwenden. Derartige hatte ich wohl seinerzeit bei der Erstellung einer größeren Pluginlösung im Einsatz.

Dürfte auch nicht stören. Nur die Exe und DLL wird (wenn keine Laufzeitpackages verwendet werden) werden von den Registrierten Klassen im "anderen Bereich" nix wissen.

Nachgeschoben: Meinst du RegisterClass der WinAPI oder der VCL?

[himitsu]

Doch, würden sie, denn RegisterClass ist keine Delphi-Prozedur.

Für die VCL-Typen werden ja im Hintergrund Windows-Klassen registriert.

[Bummi]

@Bernhard Geyer

ich habe heute morgen lange Versucht die Fälle zu reproduzieren die mir damals das Projekt so schwer (ohne BPL's unmöglich) gemacht haben (D7, diverse Komponentenpakete, XP), ich bekomme es nicht mehr hin ... ich werde schauen ob ich noch ein Beispiel dafür konstruieren kann.
In jedem Fall ziehe ich erst einmal meine Aussage bzgl. genereller Probleme zurück. :oops:

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1142702)

Doch, würden sie, denn RegisterClass ist keine Delphi-Prozedur.

Für die VCL-Typen werden ja im Hintergrund Windows-Klassen registriert.

Auch für die procedure RegisterClass(AClass: TPersistentClass) aus Classes.pas?