Eigene Klasse in einer DLL für eine andere DLL

[torud]

Hallo Wissende!

Es hört sich ziemlich kompiliziert, scheint aber doch relativ einfach zu sein. Unserer Fa. wurde eine DLL zur Verfügung gestellt, welche sportliche Statistiken aus einer speziellen Datei ausliest und in Rekords zur Verfügung gestellt.

Offenbar gibt es da ein Problem mit der Kommunikation von VB/VBS zu dieser DLL, so dass ich mit Delphi eine andere DLL erstellt habe, welche auf die externe DLL zugreift und die Daten von dieser erhält. Das funktioniert soweit ganz gut. Nun muss ich aber nicht damit arbeiten, sondern mein Kollege.

Er arbeitet aber nun wieder mit VB/VBS und kann wohl nicht diese Rekords senden/empfangen. Deshalb hat mich kein Kollege gefragt, ob es nicht möglich wäre, dass ich in der DLL eine Klasse einbaue, die im keine Rekords sondern die einzelnen Parameter der Rekords wiedergibt.

Kann mir vielleicht einer von Euch sagen, wie er das meint? Ich weiss-Ferndiagnose ist nicht so doll, deshalb hier mal der wenige Code meiner DLL.

Delphi-Quellcode:

library Project1;

uses
  ComServ;

exports
  DllGetClassObject,
  DllCanUnloadNow,
  DllRegisterServer,
  DllUnregisterServer;

{$R *.RES}

type

TDVParams = record
   PathSource: PChar;   // Path containing STATISTICS*.TOT
       IdTeam: integer;   // 0=Home, 1=Visitor
       IdPlayer: integer;   // 49=Team, 1..40 Player Jersey Number
     Skill: integer;      // 0=Tot, 1=Serve, 2=Reception, 3=Block, 4=Attack, 5=Set, 6=Defence
       SetN: integer;      // 0=Match, 1..5 Set
  end;

type
TDVOutPtsErr = record
     Pts: integer;      // Points (ITA #P + #C)
       Err: integer;      // Errors (ITA B= R= S= M= D= A= &= R/ S/)
       Tot: integer;      // Total events
  end;


function GetPointsErr(vParams: TDVParams; var vOutPtsErr: TDVOutPtsErr): integer;

begin

end;


end.

Danke für einen Tipp!

[shmia]

Zitat von torud:

Offenbar gibt es da ein Problem mit der Kommunikation von VB/VBS zu dieser DLL, so dass ich mit Delphi eine andere DLL erstellt habe, welche auf die externe DLL zugreift und die Daten von dieser erhält. Das funktioniert soweit ganz gut. Nun muss ich aber nicht damit arbeiten, sondern mein Kollege.

Eine DLL mit "normalen" Funktionen ist hier nicht die richtige Lösung.
Deutlich besser wäre eine ActiveX-DLL mit einer Automatisierungsschnittstelle.
Auf diese Automatisierungsschnittstelle kann sogar aus VBScript ohne grossen Aufwand zugegriffen werden.
Also steht an 1. Stelle die Entscheidung "normale" DLL oder ActiveX DLL an.

[torud]

Vielen Dank für diesen Hinweis!

Du kannst Dir aber sicher meine Verwunderung über Deine Aussage vorstellen, wenn ich Dir sage, dass diese DLL meine erste selbst erstellte war und ich noch nicht wirklich weiss, was ich mit Deiner Aussage anfangen soll.

Aber ich werde mal in der OH nachschauen...

Vielleicht bekomme ich noch einen Tipp dazu!?

[shmia]

Zitat von torud:

Du kannst Dir aber sicher meine Verwunderung über Deine Aussage vorstellen, wenn ich Dir sage, dass diese DLL meine erste selbst erstellte war und ich noch nicht wirklich weiss, was ich mit Deiner Aussage anfangen soll.

Also:
Eine "normale" DLL exportiert Funktionen. Alle Funktionen sind unabhängig von einander.

Eine ActiveX-DLL exportiert Interfaces (Schnittstellen) auf Objekte. (ist also objekt-orientiert)
Man erkennt eine ActiveX-DLL daran, dass die Funktionen

Code:

  DllGetClassObject, 
  DllCanUnloadNow, 
  DllRegisterServer, 
  DllUnregisterServer

exportiert werden.
Um eine ActiveX-DLL zu erstellen brauchst du Know-how über Interfaces, Typbibliotheken, den TLB-Editor von Delphi, IDispatch und Automatisierung.
Als minimale Delphi-Version: Delphi 5.
Um Dir dieses Know-How anzueignen brauchst du 2 Wochen bis 3 Monate.
Buchvorschlag: COM / DCOM / COM+ mit Delphi von Andreas Kosch