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

[samso]

Zitat von Aviator:

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.

[Aviator]

Zitat von samso:

Aber das ist ja eigentlich nicht das Thema.

Naja bedingt ja schon. Zacherl hat ja darauf hingewiesen, dass FastMM da ein Auge drauf hat. Natürlich würde ich dann auch ganz gerne wissen wie ich Fehler (auch im Bezug auf DLL Programmierung) finde wenn denn welche auftreten. Ich will natürlich jetzt nicht für alle möglichen kleinen Fragen eine extra Thread öffnen. Das kommt mir dann immer so unnötig viel / überflüssig vor.

[samso]

Vielleicht hilft Dir das ja weiter:

http://www.delphipraxis.net/183846-f...nshutdown.html

und natürlich

Quelltext FastMM

[Aviator]

Zitat von samso:

Vielleicht hilft Dir das ja weiter:

http://www.delphipraxis.net/183846-f...nshutdown.html

und natürlich

Quelltext FastMM

Danke. Werde ich mir mal anschauen.

Trotzdem bleibt für mich immer noch das Problem, dass ich noch nicht den 100%igen Durchblick habe, wie ich denn die DLL jetzt aufbauen muss. Kann da vielleicht mal jemand ein kleines Beispiel machen.

Pseudoabfrage von einem SQL-Server und Übergabe der Daten an mein Programm. Die Funktion wird dann logischerweise aus dem Programm heraus aufgerufen. Wäre sowas machbar?

[jaenicke]

Also wir benutzen Interfaces. Das hat den enormen Vorteil, dass die reine DLL Schnittstelle sehr schlank sein kann. Wir haben eine Funktion in der DLL, die von der Anwendung aufgerufen wird nachdem die DLL geladen ist. Diese bekommt das Anwendungsinterface. Darüber meldet sich umgekehrt die DLL an der Anwendung an und übergibt ebenfalls ein Interface.

Darüber können nun Interfaces bei der Anwendung registriert oder angefordert werden.

Es gibt eine Klasse TApplicationInterface, die das ganze kapselt. Und dann geht das ganze direkt generisch. Zum Beispiel funktioniert dann das sowohl in DLL als auch in der Anwendung:

Delphi-Quellcode:

var
  Params: IInterfaceGetterParams;
  Data: IDataset;
begin
  Params := TDatabaseGetterParams.Create(TDatasetKind.Query, 'select * from foo');
  Data := TApplicationInterface.Get<IDataset>(Params);
  while not Data.Eof do
  ...

Interfaces kennen ja nun keine generischen Methodenparameter. Das funktioniert daher, indem die Klassenmethode Get die GUID des generischen Parameters ermittelt und über das Interface an der Hauptanwendung diese GUID und das Parameterinterface übergibt. Dort wird dann über die GUID die registrierte Factorymethode ermittelt, mit der das Interface geholt werden kann, und mit dem Parameterinterface aufgerufen.

Natürlich kann man bei wenigen Interfaces (bei uns sind es eben sehr viele) auch im Interface der Hauptanwendung direkt z.B. eine Methode GetDataset: IDataset usw. anlegen und braucht keine Generics dafür.

[Aviator]

Also Interfaces würde ich ja auch benutzen. Das steht außer Frage. Nur stehe ich auf dem Schlauch, was das Abrufen von Ergebnissen vom SQL-Server und das Übergeben der Ergebnisse an die Anwendung angeht. Innerhalb meiner Anwendung würde ich die Ergebnisse gerne in Form eines Objektes zwischenspeichern. Um mal bei den Benutzern zu bleiben als Instanz bzw. mehrere Instanzen eines TUser Objektes.

Wäre es sinnvoll so etwas zu tun? Nur mal als Beispiel und hier im Editor runtergetippt.

Delphi-Quellcode:

IUserExchanger = interface(IInterface)
  procedure AddNewUser(const Username: string; FirstName: string; LastName: string);
  procedure AddUserGroup(const ID: Integer; const Name: string);
  [...]
end;

Die DLL Exportiert dann eine Funktion GetUsers oder wahlweise auch GetInstance die als Parameter eine Instanz eines IUserExchanger Objektes erwartet.

Delphi-Quellcode:

IUserInterface = interface(IInterface)
  procedure GetUsers(UserExchanger: IUserExchanger);
end;

Delphi-Quellcode:

TUserExchanger = class(TInterfacedObject, IUserExchanger)
private
  FUsers: TObjectList<TUser>;
  User: TUser;
public
  procedure AddNewUser(const Username: string; FirstName: string; LastName: string);
  procedure AddUserGroup(const ID: Integer; const Name: string);
end;

implementation

procedure TUserExchanger.AddNewUser(const Username: string; FirstName: string; LastName: string);
begin
  User := TUser.Create;
  User.UserName := UserName;
  User.FirstName := FirstName;
  User.LastName := LastName;
  FUsers.Add(User);
end;

procedure TUserExchanger.AddUserGroup(const ID: Integer; const Name: string);
begin
  User.Groups.Add(ID, Name);
end;

Nur mal so ein Gedanke. Falls da etwas unklar sein sollte, dann versuche ich gerne es etwas besser zu beschreiben.

Macht man so etwas oder gibt es da Nachteile? Laut Zacherl wäre es ja auch mittlerweile kein Problem mehr, Strings direkt auszutauschen. Beide Anwendungen die darauf zugreifen sind in Delphi geschrieben.

Wenn das doch nicht gehen sollte, würde dann so etwas funktionieren? Bitte auf das PChar achten. Das Interface habe ich hierfür nicht extra noch einmal geschrieben.

Delphi-Quellcode:

procedure TUserExchanger.AddUserGroup(const ID: Integer; const Name: PChar);
var
  LName: string;
begin
  LName := Name;  
  User.Groups.Add(ID, LName);
end;

[Aviator]

Hat hierzu noch jemand eine Idee? Kann man das so machen bzw. macht man das überhaupt so wie in meinem Beispiel gezeigt?

Wenn nicht, dann wäre es super wenn mir vielleicht jemand ein Beispiel machen könnte wie man so etwas am Elegantesten löst. Ich finde hierzu irgendwie keine passenden Informationen oder kann sie zumindest nicht auf meinen Fall anwenden.

[MyRealName]

Ich gebe mal eine Weisheit dazu (als alter DLL Programmierer), die ich für wichtig halte und in Deinem Fall für extrem wichtig, da Du ja von unerschiedlichen Programmen auf dynamisch erzeugte records zugreifen willst :

Speicher wird dort freigegeben, wo er erzeugt wurde.

Ich handle das wie folgt : Einen Standard-Record, der eine FreeMem procedure enthält, und die dann im record andere Daten enthalten kann wie einen Pointer und Pointer-Grösse, was dann an die FreeMem-Routine durch den record mitgegeben wird.

Code:

Type RDllRec = packed record
       P : Pointer;
       Size : Int64;
       FreeMemProc : TFreeMemProc; 
     end;
     PDllRec = ^RDllRec;

Der Pointer P im record enthält Deine eigentlichen Daten. Du rufst dann FreeMem auf mit dem record, welcher übergeben wurde, der zerstört Speicher :

Code:

procedure MyFreeMemProc(pData : PDllRec);
begin
  FreeMem(pData^.P, pData^.Size);
  Dispose(pData);
end;

Der FreeMemProc musst natürlich MyFreeMemProc zuweisen, welche dort ist wo der Speicher erzeugt wurde (also in der DLL).