Pointer auf Oberklassen

[theomega]

Und warum sind die nicht kompatibel? TIBQuery ist doch ein Nachfahre von TQuery, oder? Ich kann mich halt nicht entscheiden, weil ich nachher eine DLL für Interbase und eine für MySQL benutzten will. Mein Hauptprogramm soll es ganz egal sein, was für eine Datenbank die DLL nutzt.

[edit] OK, simmt, sorry, du hast recht, TIBQuery ist ein Nachfahre von Tdataset nicht aber von TQuery![/edit]


ich habe das mal auf total simplen Code verringert:

Delphi-Quellcode:

var
  qrmain: TIBQuery;
  p:pointer;


procedure TForm1.Button1Click(Sender: TObject);
begin
qrmain := TIBQuery.Create(nil);
p := @qrmain;
end;

procedure TForm1.Button2Click(Sender: TObject);
var tempqr:TQuery;
begin
tempqr := TQuery(p^);

tempqr.Sql.Text := 'SELECT * FROM tabelle';
tempqr.ExecSQL;
end;

Und genau das schlägt auch schon fehl. Es liegt also nicht an der DLL sondern an der Funktion an sich!

[Phoenix]

Alternativ, wenn Dir das Hilft, kannst Du ein TDataSet übergeben. Das ist die Basisklasse, aus der TIBDataSet -> TIBQuery und TBDEDataSet -> TQuery abgeleitet sind.

[Phoenix]

Zitat:

Zitat von theomega

Und warum sind die nicht kompatibel? TIBQuery ist doch ein Nachfahre von TQuery, oder?

Eben nicht.
Hierarchie von TIBQuery:

TObject -> TPersistent -> TComponent -> TDataSet -> TIBCustomDataSet -> TIBQuery

Hierarchie von TQuery:

TObject -> TPersistent -> TComponent -> TDataSet -> TBDEDataSet -> TDBDataSet -> TQuery

Wie man sieht sind die Dinger nur bis TDataSet miteinander kompatible Typen.

[Phoenix]

An der Stelle wird Dir nichts anderes übrig bleiben, als eine Wrapper-Klasse zu schreiben, die eine TQuery und eine TIBQuery als Member-Variablen hat.

Du übergibst einen TDataSet-Pointer.

Je nach dem, was übergeben wird (If myDataSet is TIBQuery oder eben If myDataSet is TQuery..) musst Du die jeweilige interne Variable belegen und alle Aufrufe inten auf das entsprechende Objekt umleiten.

Das ist so die einfachste Möglichkeit die ich sehe.

[negaH]

Zitat:

Und warum sind die nicht kompatibel? TIBQuery ist doch ein Nachfahre von TQuery, oder?

Selbst eine EXE.TQuery ist nicht kompatibel mit DLL.TQuery.
Klassen können nicht aus DLL's übergreifend benutzt werden !! Nur wenn die EXE und die DLL die Packages VCL??.bpl und VCLDB??.bpl verwenden können Klassen die in diesen Packages deklariert wurden übergreifend benutzt werden.
Wird das nicht so gemacht dann linkt der Compiler für die EXE und die DLL jeweils separat die komplette VCL ein. Somit ist die Klasse TQuery in der EXE nicht mehr identisch mit der Klasse TQuery in der DLL. Sie sind zwar Speicherkompatibel, also der Klassenrecord in den Codesegemnten der EXE und DLL sind identisch aufgebaut aber es sind NICHT der gleiche Record, eg. Speicherbereich. Da z.B. der IS und AS Operator aber auf der Speicheradresse der Klassendefinition aufbaut funktionieren diese Operatoren nicht mehr. D.h. eine TQuery erzeugt in der DLL würde bei der Abfrage if (DLLQuery is TQuery) then ; in der EXE immer FALSE liefern.

Es ist also falsch DLL's zu bauen die mit Klassen arbeiten auf die die EXE zugreifen will. Es sei denn man benutzt Packages.

Gruß Hagen

[Phoenix]

Ouch. Man lernt nie aus...
Das dürfte sich also generell schwierig gestalten...

[theomega]

So eine Kacke, ihr habt recht:
jetzt läuft es ohne jegliche Schutzverletzungen, nur mein Dataset hat nie ein Ergebniss. Fällt jemanden von euch was anderes ein? Ist das mit dem package schwierig?

Ein konzept sehe so aus:

Code:

Hauptanwendung:      DLL1:         DLL2:

qrmain:TDataSet      qrmain:TIBQuery      qrmain:TZeosQuery

jetzt soll jeder Zugriff auf die qrmain, automatisch an die jeweilge DLL weitergeleitet werden, in das jeweilige Objekt!

[negaH]

Zitat:

Das dürfte sich also generell schwierig gestalten...

Nicht unbedingt. Alle Module die gemeinsam auf Klassen zugreifen wollen müssen die Packages die diese Klassen deklarieren benutzen. Z.b. eine EXE lädt eine Formular DLL und eine Report DLL. Alle drei Module benutzen die Packages VCL??.bpl und VCLDB??.bpl. Da nun die gemeinsam genutzen Klassen in diesen Packages enthalten sind existiert deren Klassendefinition auch nur EINMALIG im Package. Alle Zugriffe auf diese Klasse aus der EXE und den beiden DLL's laufen auf Zugriffe in das Packages hinaus. Somit ist alles wieder richtig, denn diese Klasse existiert global für alle anderen Module nur einmal. Als Seiteneffekt bei größeren Projekten reduziert sich der Resourcenverbrauch. Z.b. ein Projekt mit 1 EXE und 50 Formular-DLL's + 200 Report-DLL's benötigt pro DLL ca. 50 Kb. 251 * 50Kb = 13Mb + Packages 7Mb = 20Mb für alle Module.
Ohne Packages werden alle benötigten Parts der VCL in das Modul eingelinkt. Wir wissen das eine einfache EXE dann sofort 400Kb groß wird. Dies trifft auf DLL's genauso zu. Also: 251 * 400Kb = 100Mb, schon 4 mal soviel wie mit Packages.

Grundsätzlich kann man die VCL+Klassen nicht in einfache DLL's global benutzen. Ich weis es gibt im WEB viele Anleitungen wie man zB. Formulare in DLL's benutzen kann, aber im Grunde sind diese alle falsch.

Gruß Hagen

[negaH]

Zitat:

Ist das mit dem package schwierig?

Nein, nicht im geringsten. In den Projektoptionen der DLL+EXE einfach die Checkbox "Mit Packages compilieren" anhacken. Dann im Edit der benötigten Packages nur die Packagenamen eintragen die übergreifend benutzt werden sollen. In meinen Projekten nutzte ich dann ausschließlich Packges. Zusätzlich verfrachte ich das komplette Hauptformular ebenfalls in ein eigenes Packages, z.B. Main.bpl. Die EXE wird dann ca. 15 Kb groß sein, und alle DLL's benutzen ebenfalls das Package Main = Hauptformular. Somit haben diese DLL's auch Zugriff auf das Hauptformular der Anwendung, und können sich dort registrieren usw.
Übrigens Delphis IDE arbeitet genau nach diesem Prinzip. Erzeuge mal ein Package mit folgender Register procedure und installieren es mal in der Delphi IDE.

Delphi-Quellcode:

procedure Register;
begin
  Application.Title := 'Meine Delphi IDE';
end;

Gruß Hagen

[Phoenix]

Ist das klasse...

Da bricht ja ein ganz neues Zeitalter in der Anpassung der IDE an :D