DLLs in komplexen Programm

[hans ditter]

Also, hoffe, dass ihr meine anderen Fragen weiter oben auch noch beantwortet, aber zunächst erstmal die wichtigeren Fragen:

1) Was genau ist mit Anwendungskern gemeint? Ist das so vorzustellen wie eine riesige Truhe, die alle Informationen über Komponenten und Klassen und Variablen und so weiter der Anwendung enthält?

2) Wie funktioniert das mit Interface? Was ich bisher verstanden hab ist, dass es sich dabei um eine Schnittstelle zwischen einer DLL und einem Aufrufprogramm handelt. ABER:
a) Wie funktioniert das? Wo ist der Sinn dieses Interface? --> Funktionsweise
b) Wie schreibe ich mir so ein Interface, bzw. mehrere Interfaces?
c) Welche Probleme kommen dabei auf mich zu?
d) KÖNNT IHR MIR EIN TUTORIAL EMPFEHLEN???

hans ditter

[Luckie]

Ich werfe hier einfach mal den Begriff Framework in die Runde: Werf.

Es gibt schon fertige Frameworks die schon ein fertiges Pluginsystem anbieten. Man muss also das Rad nicht neu erfinden. Ich bin mir nicht sicher, aber ich glaube von RemObjects gibt es so ein Fraework. Jedenfalls habe ich schon mal mit so einem fertigen Pluginsystem gearbeitet. In der Firma auf meinem Rechner habe ich sogar eine selbst geschriebene Anwendung liegen, die Plugins nutzt. Nur leider werde ich das nächste viertel Jahr da nicht drankommen.

@Olli: Schreib mir mal, was an deinem Tutorial gemacht werden soll. Eventuell kann ich das ein oder andere Kapitel beisteuern. Ich würde sie dir dann auch in Latex liefern können. Was Prozesse, Threads und den Kram angeht habe ich schon was fertiges auf der Platte liegen.

[hans ditter]

Hmm, leider kann ich bisher mit keiner Antwort so richtig was anfangen...

Ihr bombardiert mich mit Begriffen, die mir ein wenig unbekannt sind:
- Framework
- Interface
- Callback . . .

Also, ich habe bisher verstanden, dass:
- ich eine DLL, eine GUI und eine Unit habe, die beides miteinander kommunizieren lässt
- ich für die Kommunikation irgendwie Interfaces benutzen soll, weil das ein Vorteil birgt (??) ...
- es noch eine Unit / oder in der Management-Unit noch einen Teil geben sollte, der die Interfaces verwaltet...
- es "exorbitant wichtig ist", sich vorher klar darüber zu sein, was das Modul können soll und was es dafür braucht
- es auch noch eine Möglichkeit mit Frameworks gibt...

Leider ist das alles sehr theoretisch, und unter vielem kann ich mir nicht richtig was vorstellen. Z.B. Interfaces: Ich hab schonmal danach gegoogelt, hab mir den Link zu IUnknown angeschaut und auf der Seite auch noch nach Interface gesucht, hatte hinterher aber ungefähr genausoviel Ahnung wie vorher.

Es würde mir (denke ich) schonmal helfen, wenn ihr mir etwas Starthilfe geben könntet. Starthilfe im Sinne von: Sollte ich jetzt als erstes Mal die DLL komplett schreiben? Oder doch lieber das Ganze erstmal auf Papier theoretisch bearbeiten und dann gleick komplett umsetzen? Wo kann ich Grundwissen zu Interfaces, Frameworks und Callbacks bekommen? Wie fange ich jetzt am Besten an?

Es würde mir auch helfen, wenn ihr die Fragen, die ich in vorigen Threads schonmal gestellt hab nochmal beantworten könnt. Ich hab zumindest keine direkte Antwort auf irgendeine dieser Antworten gefunden. Falls ich mir irre, bitte drauf hinweisen, dann schau ich mir den Post nochmal genauer an!!

Danke, hans ditter

[MGC]

Hallo Hans Ditter,

Unter folgendem Link findest Du eine recht schöne Erklärung zum Einsatz von Interfaces für die PlugIn-Realisierung.
Beim Suchen in Delphi-Praxis habe ich bisher stets schnell Lösungen zu meinen Problemen gefunden.

Ansonsten hilft ofmals auch ein kleiner Blick in die recht umfangreiche Online-Hilfe von Delphi und ggf. ein Blick in die Sprachreferenz und deren mitgelieferte Anleitungen und Beispielen.

Ich kann in dieser Hinsicht nur zu Geduld und Lesebereitschaft aufrufen. Bin selbst bereits seit einiger Zeit Mitglied in der DP und musste bisher noch keine Frage selbst stellen.



http://www.delphipraxis.net/149369-p...nterfaces.html

[rapante]

Hallo Hans Ditter,

Zitat von hans ditter:

Starthilfe im Sinne von: Sollte ich jetzt als erstes Mal die DLL komplett schreiben? Oder doch lieber das Ganze erstmal auf Papier theoretisch bearbeiten und dann gleick komplett umsetzen?

Bevor du ein so komplexes Projekt angehst solltest du dich ausgiebig mit den Grundlagen beschäftigen.
Imho bringt es dir nichts eine Planung zu erstellen wenn dir der Sinn und die Funktionsweise bestimmter 'Mechanismen' nicht klar sind.

Zerlege deine Problemstellung in kleine Teileinheiten und arbeite diese nacheinander ab. In der Regel probiere ich neue Sachen dann zunächst in kleinen Testprojekten aus -
um wirklich zu verstehen wie was funktioniert...

Hier findest du z.B. noch etwas zu Interfaces.

[MGC]

Hallo Hans Ditter,

ich schließe mich Rapante an. Am besten ist es, wenn Du Dich erstmal hinsetzt und aufschreibst was Dein Programm können soll. Male Dir mal ein paar Use-cases auf (Anwendungsfälle, die Du Dir mit dem Programm vorstellst) und entwickle daraus die Anforderungen, die Du an das Programm stellst.
Daraus ergeben sich schließlich kleine Teilbereiche, die Du dann genau planst und Schritt für Schritt realisierst.
Ich weiß selbst wie es ist, wenn man darauf brennt gleich "loszulegen" und ein kleines Programm zu schreiben. Später hast Du dann sehr viel Arbeit alles in logische Teileinheiten zu sortieren udn diese wiederum sinnvoll miteinander zu verknüpfen.
An Fehlersuche und Erweiterungen gar nicht zu denken. Und mal ganz ehrlich, es kann auch wirklich Spass machen ein Programm genau durchzuplanen. Dabei lernt man sehr viel über das Vorgehen der Profis und man wird schnell feststellen, dass dann die Umsetzung viel frustfreier vonstatten geht.

Viele Grüße,
Marc

[hans ditter]

Also, erstmal danke für eure Antworten.
Ich hab mir die versch. Links mal angeschaut und durchgelesen, die beiden Foreneinträge sind mir noch zu speziell.
Das PDF-Dokument gefällt mir ganz gut. Ist halbwegs verständlich erklärt... aber eben nur halbwegs... (Die verwenden so komplizierte Namen und so...)

Also, es gibt eine DLL mit einer Klasse, die versch. Methoden implementiert (zur Verfügung stellt).
Dann gibt es noch ein Interface, welches (fast) alle Methoden dieser Klasse referenziert (also darauf zeigt).
Und schließlich gibt es wieder eine Klasse in der Hauptanwendung (HA), die eine Variable des Typs des Interface besitzt.
Korrigiert mich bitte, wenn was falsch ist!!

Alle drei genannten Sachen sollten in einer eigenen Datei liegen (DLL oder Unit).

In der Klasse der Hauptanwendung erzeuge ich eine Referenz auf das Interface. Falls dies gelingt, kann ich auf die Funktionen des Interface zugreifen.
Wenn ich also eine Prozedur P1 in dem Interface aufrufe, reicht das Interface diesen Aufruf an die Klasse in der DLL weiter, die dann ihre Aufgabe erledigt.
Ist das richtig?

Ich denke mal, meine Beschreibung ist jetzt noch seeeeehr grob...

Ich hab auch noch ein paar Fragen:

-> In dem Dokument ist immer wieder die Rede von "Basisklasse". Was sollte ich mir darunter vorstellen?

-> Auch erwähnt ist TInterfacedObject. Wozu braucht man das? Ich dachte, das übernimmt IUnknown...

-> Wie funktioniert das mit der Referenzverwaltung des Interface? Ich habe verstanden, dass, wenn eine neue Referenz erzeugt wird, der Referenzzähler von IUnknown um eins erhöht wird.
Aber wann wird der Referenzzähler wieder erniedrigt? Es hörte sich so an, als ob man sich darum überhaupt keinen Kopf machen muss...

-> Damit im Zusammenhang die letzte Frage. Der Referenzzähler zählt ja die Referenzen auf ein Objekt. Aber auf welches Objekt? Das Objekt das aus der Klasse in der DLL erzeugt werden kann? Oder die Referenzen auf das Interface?

Würde mich freuen, wenn ihr mir weiterhin so gut helfen würdet! Danke!

LG, hans ditter

[MGC]

Guten Morgen Hans Ditter,

ich sehe schon, es geht Dir ähnlich wie mir am Anfang. Delphi/Object Pascal und OOP (ObjektOrientierte Programmierung) sind auf den ersten Blick sehr verwirrend und umfangreich und viele Dinge (Klassen und deren Vererbung) erscheinen oftmals als schier unüberblickbare Konstrukte, deren Sinn sich einem einfach nicht erschließen möchte. Doch hat man erst einmal die Logik verstanden, ergeben sich plötzlich ungeahnte Möglichkeiten.

Für einen besseren Einstieg kann ich hier zwei Seiten empfehlen, die mich persönlich beim Einstieg bestens unterstützt haben:

Delphi-Lehrgang Einsteiger:
http://delphi.zsg-rottenburg.de/lektionen.html

Tutorials für Delphi:
http://www.michael-puff.de/Programmi...phi/Tutorials/

Bei den Tutorials zu Delphi von Michael Puff solltest Du Dir besonders die ersten drei Tutorials durchlesen (COM, Container-Klassen und Klassen), aber eins nach dem Anderen. Im Grundlehrgang findet sich eine sehr gute Erläuterung zur Klassendefinition (Ableiten von Basisklassen, Vererbung usw.).

Ich werde auch mal sehen, ob ich genügend Zeit aufbringen kann und mal ein kleines Beispiel zu Interfaces schreibe (Kann ich aber noch nicht versprechen).

Viele Grüße,
Marc