Mit DLLs arbeiten

[Luckie]

Zitat von dor557:

Ich verzichte auf Strings denn Pchar's sind nichts anderes

Autsch. Ein String ist ein Zeiger auf eine Zeichenkette. Ein PChar ist ein Zeiger auf ein Charakter-Array. Das sind zwei absolut unterschiedliche Dinge.

Zitat:

und umwandeln ist einfach

Aber nur dank der Compiler Magic.

Zitat:

und die Speicherauslastung in der DLL und der anwendung ist auch gleiner.

Kann man so generell nicht sagen. Eher umgekehrt, da Strings nur kopiert werden im Speicher, wenn es nötig ist, ansonsten wird immer nur eine Referenz auf den original String gesetzt.

Zitat:

Sollte man auf diese ShareMem dll nicht verzichten wird das Projekt unnötig in die Grösse gezogen.

Das wäre für mich weniger das Problem. Man muss ben nur daran denken, die ShareMem.dll mit auszuliefern.

@DeddyH: das war ein trivial Beispiel. Interesannt wird es aber erst, wenn die DLL Zeichenketten zurückgeben soll. Wie das geht, siehe hier: http://www.michael-puff.de/Artikel/2...String_DLL.php

@Henry: Innerhalb der DLL kannst du machen, was du willst. Du musst eben nur dann aufpassen, wenn du die Grenzen der Speichermanager (Programm, DLL) überschreiten willst.

Zum Verständnis wie das mit den Speichermanager funktioniert, siehe hier: http://www.michael-puff.de/Artikel/2...ingsAusDLL.php

[thabaker]

Zitat:

Außerdem mein üblicher Hinweis bei dem Thema: WideString lässt sich ohne Tricksereien zwischen Echse und DLL (und auch anderen Sprachen, weil normaler OleString aka BSTR)

ist das tatsächlich so? das wäre ja toll, weil widestrings eh immer mehr Verbreitung finden.

[Henry]

Zitat von Luckie:

@Henry: Innerhalb der DLL kannst du machen, was du willst. Du musst eben nur dann aufpassen, wenn du die Grenzen der Speichermanager (Programm, DLL) überschreiten willst.

OK. Dann könnte ja mein neuer Ansatz klappen, ich werde dann bei der Übergabe von und zur DLL mit PChar arbeiten.
Mal schauen ob es klappt.

Danke erst einmal für die Hilfe.

[Elvis]

Zitat von thabaker:

Zitat:

Außerdem mein üblicher Hinweis bei dem Thema: WideString lässt sich ohne Tricksereien zwischen Echse und DLL (und auch anderen Sprachen, weil normaler OleString aka BSTR)

ist das tatsächlich so? das wäre ja toll, weil widestrings eh immer mehr Verbreitung finden.

Ja klar.
WideString ist etwas langsamer als AnsiString, da es kein nativer Delphi typ ist (keine Referenzzählung, und auch noch Unicode...).
Sollte aber nicht viel ausmachen. PChars sind nicht nur heikel, weil man vergessen könnte den String vorher explizit zu kopieren, sie machen deine Anwendung auch viel anfälliger für Buffer overflows.
Egal ob unbeabsichtigt, oder als Sicherheitslücke, die andere gezielt ausnutzen könnten...
Und wie gesagt, der Code, der mit PCHars arbeitet ist einfach nur hässlich.

PChars innerhalb von optimierten Funktionen zu nehmen um Kopiererei zu sparen ist eine Sache (und das macht auch Sinn!), aber sich sinnlos auf diese mittelalterliche Art unnötige Bufferflows oder Umwege anzutun kann ich nicht ganz nachvollziehen...
Wenn du weißt, dass die DLL von dir kommt, dann wären auch AnsiString und FastMM ein schöne Lösung.

[Henry]

Hallo Robert,

in meinem Fall wäre ich mir sicher das Die DLL von mier kommt
Ich hätte auch prinzipiell kein Problem damit die BORLNDMM.DLL mit meinem Programm auszuliefern.
Ich konnte bisher allerdings noch nirgendwo finden wo diese Datei hin muss, damit es funktioniert.
Reicht es wenn sie im Programmverzeichnis liegt? So lange es dort liegen kann wäre das auch eine Option für mich.
Ich installiere nämlich ungern Dateien in das Systemverzeichnis von jemand anderem.

Ein Weiteres Problem ist, wo ausser in der DLL muss ich noch die Unit ShareMem (als erstes) einbinden?
Reicht es in der Unit im Programm wo ich die Funktionen importiere, oder auch in allen Units wo ich dann die importierten Funktionen aufrufe?

[Elvis]

Zitat von Henry:

Hallo Robert,
in meinem Fall wäre ich mir sicher das Die DLL von mier kommt

Na dann nimm gleich String.
Oder explizit AnsiString, falls du Angst vor binären Inkompatibilitäten mit der nächsten Delphiversion hast. Da dort "String" auf einen UTF16-basierten String zeigen wird.

Zitat:

Ich hätte auch prinzipiell kein Problem damit die BORLNDMM.DLL mit meinem Programm auszuliefern.
...
Ein Weiteres Problem ist, wo ausser in der DLL muss ich noch die Unit ShareMem (als erstes) einbinden?
Reicht es in der Unit im Programm wo ich die Funktionen importiere, oder auch in allen Units wo ich dann die importierten Funktionen aufrufe?

Das ist (fast) alles ein furchtbares Relikt der Vergangenheit.
Ziehe dir FastMM und packe den als erste Unit in die Uses clause von allen .DPRs.
WideString ist aber trotzdem nicht aus dem Rennen und würde von dir gar nix spezielles erfordern...

[Henry]

Hallo,

mein Problem ist hauptsächlich, dass ich nicht nur Strings einzeln übergeben möchte.
Ich hatte schon einmal im DelphiForum einen Beitrag zu meinem eigentlichen Problem gestartet und bin immer noch am tüfteln, da es nicht klappt.

Ich möchte nämlich komponenten an die DLL übvergeben (z.B. StringGrid) Siehe: Beitrag im DF

Und dann habe ich hier das Thema gefunden und dachte, frege ich hier mal nach dem Umgang mit dem Speichermanager.
Es kann natürlich auch sein das ich da noch ein ganz anderes Problem habe.
Kannst es Dir ja mal anschauen, vieleicht hast Du ja eine Idee für mich.

Nach FastMM werde ich mal schauen, oder hast du ne Quelle parat?

Danke

[Elvis]

Zitat von Henry:

Ich möchte nämlich komponenten an die DLL übvergeben (z.B. StringGrid)

Das mag jetzt überraschend kommen, aber Objekte and die DLL zu übergeben hat (fast) gar nichts mit dem Speichermanager zu tun.
Damit das geht müssen alle Packages, die für die Komponenten benötigt werden als Laufzeit-Packages von DLL und Echse referenziert werden.
Das heißt, du musst mindestens die RTL, VCL mitliefern und als Laufzeit Packages angeben. (Unter "Packages" in den Projektoptionen)
Das ist die einzige Möglichkeit, damit TStringGrid in der DLL das gleiche wie TStringGrid in der Echse ist.

Eine andere Möglichkeit wäre es, wenn du dein StringGrid in ein Interface mit den Methoden verpackst, die du benötigst.
Dann bräuchtest du in der DLL nur das Interface benutzen, ohne den Rattenschwanz an Packages mit schleppen zu müssen. (Du kannst hier nach DLL und Interfaces suchen)

Packages sind eigentlich ein sehr furchtbares Format für eine Bibliothek, da sie immer nur mit einer ganz speziellen Version des Compilers laufen. Du kannst mit Packages nicht die DLL mit Delphi 7 und die Echse mit 7.1 kompilieren.

[Henry]

Ohje, da habe ich mir ja was einfallen lassen.
Ich werde deinem Suchtip mal folgen und schauen ob ich das dann hinbekomme.
Hört sich für mich erst mal kompliziert an. Aber mit diesen Packages werde ich dann mal die Finger von lassen, ohne wäre mir auch lieber.

Danke Dir erst einmla für die Hilfe.
Wenn ich noch fragen dazu habe werde ich mich entweder in einem neuen Beitrag oder per PM melden, denn ich denke das passt dann nicht mehr hier zum Thema