DLL Programmierung - Wie übergebe ich am sinnvollsten meine Daten?

[Aviator]

Hallo zusammen,

in letzter Zeit häufen sich die Threads die ich selber öffne. :shock:

Konkret geht es darum, dass ich gerade dabei bin ein komplett neues Projekt zu beginnen. In einem anderen Thread habe ich bereits geschrieben, dass es sich um ein selbstentwickeltes DMS handelt.

Ich möchte mein Programm in ein paar Teile aufsplitten und das ganze dann in eine DLL auslagern. Das ganze wird nicht nur aus Gründen der (hoffentlich) einfacheren Updatefähigkeit so gemacht sondern auch, weil ein anderes Programm auf die Daten meines DMS zugreifen soll.

Mein Problem besteht jetzt darin das ich nicht weiß, wie ich denn die Daten die meine DLL beschaffen soll (von einem SQL-Server) in meine bzw. die Fremde Anwendung "rüberreichen" kann/soll. Das ich hierzu ein Interface verwenden sollte ist schonmal klar. Für einen anderen einfacheren Fall habe ich auch bereits. Die Frage ist nur, wie baue ich das richtig auf. Das Problem ist ja schonmal die Übergabe von String die dann als PChar übergeben und dann in der Anwendung einem String zugewiesen werden müssen. Das ist so hoffentlich korrekt. :gruebel:

Um mal ein konkretes Beispiel zu nennen:

• Meine Anwendung (das DMS) legt diverse Benutzer in einer Datenbank an
• Mein Programm muss beim Start von einer DLL diese Benutzer wieder zurückerhalten um eine Auswahlform zu erzeugen bei der der Nutzer wählen kann, mit welchem Benutzernamen er sich anmelden will
• Die andere fremde Anwendung soll das ebenfalls können

Ein Benutzerobjekt besteht aktuell aus den folgenden Teilen:

• Benutzername
• Vorname
• Nachname
• evtl. verschlüsseltes Passwort (wird aber wahrscheinlich in der DLL gegengeprüft und somit nicht an die eigene bzw. fremde Anwendung weitergegeben
• E-Mail Adresse
• evtl. Berechtigungen in Form eines Int64 Wertes

Wie muss ich jetzt mein Interface respektive meine DLL aufbauen, damit ich solche Informationen zurückgeben kann? Ein Objekt zwischen Anwendung und DLL zu tauschen ist ja nicht optimal habe ich mal hier gelesen. Wie funktioniert so etwas richtig und auf was muss ich achten? Bin für jeden Tipp dankbar.

[Zacherl]

Zitat:

Zitat von Aviator (Beitrag 1349370)

Ein Objekt zwischen Anwendung und DLL zu tauschen ist ja nicht optimal

Stimmt, auf Objekte solltest du verzichten, aber Records stellen kein Problem dar. Insbesondere, wenn alle DLLs und Anwendungen in Delphi geschrieben sind und die selben Compileroptionen verwenden. Bezüglich Strings: Die gleiche Vorraussetzung annehmend, kannst du mitlerweile "glaube" ich sogar direkt Strings statt Pointer (PChar) verwenden. Ich meine gelesen zu haben, dass FastMM4 sowas selbstständig handhabt. Müsstest du am besten aber nochmal ausprobieren.

[Aviator]

Zitat:

Zitat von Zacherl (Beitrag 1349371)

Zitat:

Zitat von Aviator (Beitrag 1349370)

Ein Objekt zwischen Anwendung und DLL zu tauschen ist ja nicht optimal

Stimmt, auf Objekte solltest du verzichten, aber Records stellen kein Problem dar. Insbesondere, wenn alle DLLs und Anwendungen in Delphi geschrieben sind und die selben Compileroptionen verwenden. Bezüglich Strings: Die gleiche Vorraussetzung annehmend, kannst du mitlerweile "glaube" ich sogar direkt Strings statt Pointer (PChar) verwenden. Ich meine gelesen zu haben, dass FastMM4 sowas selbstständig handhabt. Müsstest du am besten aber nochmal ausprobieren.

Also die Anwendungen sind beide in Delphi geschrieben. Bei der Übergabe von Records habe ich aber auch gelesen, dass es da Probleme gibt/geben kann. FastMM4 verwende ich nicht. Sollte man das denn? Bisher bin ich ganz gut ohne einen fremden MemoryManager klar gekommen.

[Zacherl]

FastMM ist seit längerem der Standard MemoryManager von Delphi :) Ja, es war früher so, dass es Probleme geben konnte, wenn die Records Felder mit Referenzzähler enthalten bzw. Felder, die finalisiert werden müssen (dyn. Arrays, Strings, etc). Wie gesagt: Am besten mal ausprobieren. Records mit primitiven Datentypen machen auf jeden Fall zu 100% keine Probleme.

[Aviator]

Achso ok. :oops:

Jetzt stelle ich mir nur die Frage, wie ich denn dann mein Interface aufbaue. Ich muss ja mehrere - in dem Fall dann Records - übergeben. Nämlich pro User der in der Datenbank angelegt wurde einen. Das wiederum wäre dann ja wieder ein Array of TUserData oder so.

Kann ich also bedenkenlos einen Record aufbauen in dem ein bzw. mehrere Strings enthalten sind? Wie stelle ich das am besten an?

[Zacherl]

Also wenn du komplett sichergehen willst, nimmst du für String-Felder

Delphi-Quellcode:

ShortString

bzw.

Delphi-Quellcode:

array[0..n-1] of Char

. Hierbei ist es wichtig, dass die Größe statisch ist. Zum Zurückgeben eines Arrays mit dynamischer Anzahl von Elementen, kannst du dich an der Windows API orientieren. Die handhabt sowas in folgender Form:

Delphi-Quellcode:

type
  PRecord = ^TRecord;
  TRecord = record
    Field1: Integer;
    Field2: array[0..255] of Char;
  end;

function ReturnArrayOfRecords(Records: PRecord; Size: DWord; var NumberOfRecords: Integer): Boolean;

Auf der anderen Seite sieht das dann folgendermaßen aus:

Delphi-Quellcode:

var
  Records: PRecord;
  Size: DWord;
  I, NumberOfRecords: Integer;
begin
  // NumberOfRecords ermitteln
  ReturnArrayOfRecords(nil, 0, NumberOfRecords);
  Size := NumberOfRecords * SizeOf(TRecord);
  GetMem(Records, Size);
  try
    // Daten ermitteln
    if (ReturnArrayOfRecords(Records, Size, NumberOfRecords)) then
    begin
      for I := 0 to NumberOfRecords - 1 do
      begin
        // Arbeite mit Record #I
        Inc(Records);
      end;
    end;
  finally
    FreeMem(Records);
  end;
end;

Alternativ kannst du statt der Pointer hier auch ein dynamisches Array und

Delphi-Quellcode:

SetLength

verwenden.

[Aviator]

Irgendwie stehe ich gerade auf dem Schlauch. Es ist nicht so, dass ich deine Antwort nicht verstehen würde, aber es hat noch nicht so richtig "klick" gemacht. :evil:

Ich hänge immer nochdabei, wie ich das auf mein Programm anwenden soll. Es kann doch nicht so schwer sein, eine DLL zu programmieren.

Wie binde ich denn eigentlich FastMM4 ein. Ein

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := True

wird es ja bestimmt nicht nur gewesen sein, oder? Eine Unit FastMM4 gibt es bei mir nicht. CnPack findet bei der Eingabe lediglich die Unit FastMMMemLeakMonitor. Aber so wie ich das gehört habe, gehört da ja noch ein bisschen mehr dazu, oder?

ReportMemoryLeaks... zeigt ja am Schluss auch nur eine MessageBox an bei der ich danach selbst auf die Suche nach dem Fehler gehen muss. Ich dachte FastMM4 wäre da etwas ... naja ... aussagekräftiger.

[samso]

FastMM4 muss nicht mehr manuell eingebunden werden. Der ist immer eingebunden.

[Aviator]

Zitat:

Zitat von samso (Beitrag 1349388)

FastMM4 muss nicht mehr manuell eingebunden werden. Der ist immer eingebunden.

Das heißt also, dass sich das alles nur im Hintergrund abspielt und ich davon nix merke? Und ReportMemoryLeaks... immer noch nur dieses Standardfenster ausgibt?

Ich dachte immer, dass FastMM viel mehr Informationen zur Verfügung stellen würde. Wenn ich mich recht entsinne gab es doch eine Inc Datei in der Einstellungen vorgenommen werden konnten. Verzeiht mir die vielleicht blöden Fragen, aber damit habe ich mich nie wirklich beschäftigt.

[samso]

Zitat:

Zitat von Aviator (Beitrag 1349390)

Ich dachte immer, dass FastMM viel mehr Informationen zur Verfügung stellen würde. Wenn ich mich recht entsinne gab es doch eine Inc Datei in der Einstellungen vorgenommen werden konnten. Verzeiht mir die vielleicht blöden Fragen, aber damit habe ich mich nie wirklich beschäftigt.

Dazu muss man dann doch wieder Hand anlegen. "FullDebugMode" ist dazu das Stichwort. Aber das ist ja eigentlich nicht das Thema.