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

[taveuni]

Wenn eine Schnittstelle zu anderen Programmen zur Verfügung gestellt werden muss ist man mit (Delphi-) DLL's beschränkt. Deshalb arbeiten wir seit mehr als 10 Jahren mit RemObjects. Damit kannst Du Multitier Anwendungen erstellen und eine sehr komfortable IPC realisieren. Durch die Auswahl unzähliger Channels ist es möglich jedem eine Schnittstelle zu bieten und intern mit dem Objekten zu arbeiten (eher komfortable Records/Arrays). Du musst Dich nicht um Verbindungen, Reconnectes usw. kümmern. Ausserdem kann auch mit Events gearbeitet werden. Ist jetzt nicht direkt eine Antwort auf Deine DLL Frage. Einfach ein anderer Ansatz (der natürlich etwas kostet).

[Aviator]

Hallo taveuni,

sieht ja auch interessant aus. Nur wollte ich das alles für den Anfang ein wenig kleiner halten. Bin leider auch nicht so ein Freund davon, direkt Komponenten für ein Vorhaben zu kaufen. So etwas sollte sich ja eigentlich problemlos mit DLLs lösen lassen. Wenn man es denn kann.

Interessant sieht das aus, keine Frage. Nur weiß ich eben auch nicht, ob dass das Richtige für mich/uns ist. Und der Preis ist ja auch nicht gerade gering (um es mal vorsichtig auszudrücken).

Eine Testversion halte ich da nicht für angebracht. Ich denke, dass ich da bestimmt länger bräuchte um mich da einzuarbeiten als es der Testzeitraum zulässt. Und bevor ich nachher merke, dass es doch nicht das Richtige ist ... aber danke für den Vorschlag.

Was gäbe es denn für Alternativen? Ich habe schon sehr viel von REST gehört, weiß aber nicht ob das für meinen Fall das Richtige wäre. Könnte man das dafür verwenden? Vorteil wäre ja auch, dass ich theoretisch die Grundlage für eine Mobile Anwendung geschaffen hätte. Ist das korrekt?

[Fritzew]

Um auf Deine DLL Frage zurückzukommen:

In eine DLL Schnitstelle gehören nur einfache Typen,
also z.B

Integer,
Word,
Double,
Single,
PWideChar,
PAnsiChar etc..

Auf keinen Fall normale Strings.

Records auch nur aus diesen Typen

Das hat den Vorteil das man Compilerunabhängig ist.

Wir benutzen das heftig in mixed Projekten (Delphi, VCC, und sogar noch Fortran)

Für Records (Structs) gilt dasselbe

also
z.B Delphi :

Delphi-Quellcode:

const 
 cwmaxnamesize = 30;
type
 tApi_Materialrec = packed record
    Name: array [0 .. cwmaxnamesize - 1] of Ansichar;
    Group: array [0 .. cwmaxnamesize - 1] of Ansichar;
    MatCode: array [0 .. cwmaxnamesize - 1] of Ansichar;
    Mate1, mate2, mate3, matg1, matg2, matgew: single; // Materialgewicht

    Mattyp: integer; 
    list_matbez, 
    mat_photoflag, 
    mat_photo1, 
    mat_photo2: integer;
  end;

//C++

Code:

// Ausrichtung an Byte-Grenzen wegen Delphi
#pragma pack(push,1)

struct CHA_API_API Api_mat
{
  char      name[30], Group[30], MatCode[30];
  float     mate1,mate2,mate3, matg1,matg2,matgew;
  int      mattyp;
  int      list_matbez;
  int      photoflag, Photo1, Photo2;
};

Wenn Wir Interfaces benutzen gilt dasselbe.

einziger Unterschied ist das wir in Interface auch schon mal WideString benutzen,
da dort das Speichermanagement von Windows grift.

Funktionen geben niemals Records zurück sondern sind bei uns immer aufgebaut nach dem Schema:


function getMatDataforId(aid : Integer; var matrec : tApi_Materialrec) : Bool; Das funktioniert bei uns soweit problemlos.

[Aviator]

Hallo Fritzew,

danke für die Antwort. Das mit den Strings war mir bewusst. Nach den etlichen Tutorials die ich durchgelesen habe umso mehr.

Zitat von Fritzew:

Delphi-Quellcode:

const 
 cwmaxnamesize = 30;
type
 tApi_Materialrec = packed record
    Name: array [0 .. cwmaxnamesize - 1] of Ansichar;
    Group: array [0 .. cwmaxnamesize - 1] of Ansichar;
    MatCode: array [0 .. cwmaxnamesize - 1] of Ansichar;
    Mate1, mate2, mate3, matg1, matg2, matgew: single; // Materialgewicht

    Mattyp: integer; 
    list_matbez, 
    mat_photoflag, 
    mat_photo1, 
    mat_photo2: integer;
  end;

Funktionen geben niemals Records zurück sondern sind bei uns immer aufgebaut nach dem Schema:


function getMatDataforId(aid : Integer; var matrec : tApi_Materialrec) : Bool; Das funktioniert bei uns soweit problemlos.

Die Funktion hätte ich auch mit einem Var Parameter aufgebaut, da ich das so auch aus der WinAPI kenne.

Wie wird denn jetzt die von dir beschriebene Funktion aufgerufen. Muss das dann auch zwingend ein Array of AnsiChar sein? Kann man da nicht einfach eine Variable vom Typ PChar nehmen? Und wenn ja, wie läuft der Aufruf dann ab sofern sich da was ändern sollte. Meine Ergebnisse können eine unterschiedliche Länge haben die ich vorher nicht kenne. Infolge dessen kann ich auch keine festen Arrays nehmen.

[Fritzew]

Wenn Du mit unterschiedlichen Datenlängen hantieren willst muss Sichergestellt werden wem der Speicher gehört.
Also brauchst Du dann zusätzliche Funktionen um den Speicher zu verwalten.

Ähnlich wie es ja an vielen Stellen in der WINAPI gemacht wird.

entweder vorher nachfragen wieviel Speicher benötigt wird
oder eine Funktion um allozierten Speicher wieder freizugeben.

Wobei immer die alte Regel gilt das nur der Freigibt der auch angefordert hat.

[Aviator]

Zitat von Fritzew:

Wenn Du mit unterschiedlichen Datenlängen hantieren willst muss Sichergestellt werden wem der Speicher gehört.
Also brauchst Du dann zusätzliche Funktionen um den Speicher zu verwalten.

Ähnlich wie es ja an vielen Stellen in der WINAPI gemacht wird.

entweder vorher nachfragen wieviel Speicher benötigt wird
oder eine Funktion um allozierten Speicher wieder freizugeben.

Wobei immer die alte Regel gilt das nur der Freigibt der auch angefordert hat.

Okay. Habe zwar bisher wenig mit der WinAPI gearbeitet, aber das Prinzip habe ich verstanden. Allerdings hänge ich bei der Umsetzung noch ein wenig.

Wärst du so nett und würdest mir vielleicht ein Minimalbeispiel anhängen wie das dann in der Anwendung und der DLL auszusehen hat?

Ich denke die Lösung mit dem Anfragen wie viel Speicher benötigt wird ist die "bessere", da sie an die WinAPI angelehnt ist. Oder siehst du das anders?

[EDIT]Vergessen zu erwähnen. Ein Record müsste bei mir in etwa so aussehen (könnte auch noch erweitert werden):

Delphi-Quellcode:

TDocumentData = record
  DocumentID: Int64;  // Kann man den benutzen oder ist man da auf Integer beschränkt? Wäre sehr schlecht.
  DocumentName: PChar; // Normalerweise String (der wäre theoretisch auf 255 Zeichen begrenzt, könnte aber auch erweitert werden)
  DocumentDescription: PChar; // Hier steht eine Beschreibung die evtl. sogar RichText beinhalten soll
  Deleted: Boolean; // Der sollte ja keine Probleme machen, oder?
end;

[/EDIT]

[Fritzew]

Delphi-Quellcode:

unit Unit10;

interface
  uses
   sysutils;
type
 {$ALIGN 4}
 TDocumentData = record
  DocumentID: Int64; // Kann man den benutzen oder ist man da auf Integer beschränkt? Wäre sehr schlecht.
  DocumentName: PChar; // Normalerweise String (der wäre theoretisch auf 255 Zeichen begrenzt, könnte aber auch erweitert werden)
  DocumentDescription: PChar; // Hier steht eine Beschreibung die evtl. sogar RichText beinhalten soll
  Deleted: Boolean; // Der sollte ja keine Probleme machen, oder?
end;


 function getDocumentData(const aId : Int64; var aDocument : TDocumentData): LongBool;
 procedure freeDocumentData(var aDocument : TDocumentData);

implementation

  function getDocumentData(const aId : Int64; var aDocument : TDocumentData): LongBool;
  begin
   result := false;

   // Pick up the Data
    if True then
    begin
      fillchar(aDocument, sizeof(aDocument), 0);
      aDocument.DocumentID := aId;
      // reserve memory
      aDocument.DocumentName := Strnew('Documentname');
      aDocument.DocumentDescription := StrNew('DocumentDescription');
      result := true;
    end;
  end;


  procedure freeDocumentData(var aDocument : TDocumentData);
  begin
    if aDocument.DocumentName <> nil then StrDispose(aDocument.DocumentName);
    if aDocument.DocumentDescription <> nil then StrDispose(aDocument.DocumentDescription);
    fillchar(aDocument, sizeof(aDocument), 0);
  end;


end.

Benutzung :

Delphi-Quellcode:

procedure Test;
 var data : TDocumentData;
 begin

  if getDocumentData(1, data) then
  begin
     //Use Data
     freeDocumentData(data);
  end;


 end;

Einfach mal so hingeschrieben aber du siehst den Flow denke ich

[himitsu]

packed record müssen es nicht unbedingt sein, aber man sollte dann wenigstens explizit die Speicherausrichtung definieren.
z.B.

Delphi-Quellcode:

type
  {$ALIGN 4}  // das gilt ab hier und nur bis zum Unit-Ende (oder bis zum nächsten $ALIGN in der Unit)
  TMyRecord = record
    ...
  end;

Das Selbe gibt für ENUMs, die man vielleicht gleich auf Integer festlegen sollte, da in vielen C-Sprachen die auch immer 4 Byte sind.
{$MINENUMSIZE 4}
In Delphi ist das Minimum standardmäßig 1 Byte, wenn der Enum maximal 256 Werte besitzt.