DLLs in komplexen Programm

[hans ditter]

Hallo liebe Gemeinde,

ich hatte vor einiger Zeit mal angefangen, sozusagen ein "Planungsprogramm" zu schreiben. Sollte eben in die Richtung gehen, dass man seine Ein- und Ausgaben, seine Aufgaben, Termine etc. pp. planen kann. Angefangen hab ich jetzt mit Ein- und Ausgaben und einer Übersicht für Arbeitsstunden.
Bitte keine Diskussion anfangen, ob das alles sinnvoll ist oder nicht!:D

Jetzt hab ich aber in meinem schönen dicken Delphibuch ein bisschen weitergelesen und hab endlich auch verstanden (hoffe ich zumindest ;) ), wie das mit den DLLs funktioniert.
Da dachte ich mir, mach ich dieses Planungstool mal aus Modulen (mit DLLs).
Auch hier der Hinweis: Bitte keine Diskussion über Vor- und Nachteile von DLLs...;)

Leider hab ich jetzt aber ein Problem, mir auszumalen, wie man das alles vernetzen soll.

Ich geb mal zum Besseren Verständnis ein Beispiel, was ich meine:
Man hat das Modul "Ein- / Ausgabenplanung" (Modul 1) und das Modul "Arbeitsstunden planen" (Modul 2) installiert. Das Erstere von beiden erklärt sich von selbst. Beim Zweiten gibt man in einer Maske ein, von wann bis wann man gearbeitet hat, der Computer rechnet die Gesamtzeit und den Verdienst aus und speichert dies in einer Datenbank.
Nun soll aber das Modul 1 die Werte aus der Datenbank des Modul 2 mit einbeziehen, ergo soll Modul 1 automatisch am Ende des Monats den ges. Monatsverdienst aus dem Modul 2 mit in seine Datenbank integrieren.
Aber wie organisiere ich das jetzt? Wo sollen die Komponenten für den Zugriff auf die Datenbanken liegen, wie soll man auf diese zugreifen?

Im Moment liegen Datasource etc. noch auf der Mainform und beide Teilprogramme können darauf zugreifen, doch wie mache ich das, wenn ich diese beiden Teilprogramme in DLLs auslagere? Sollte ich dann für jedes Modul dynamisch eine Zugriffskomponente im Hauptprogramm anlegen, auf die dann zugegriffen werden kann?

Hoffe ihr könnt mir noch folgen,

frohe Adventsgrüße, hans ditter

[hoda]

Ich denke, dass es viele Wege gibt wie man das löst.Das Problem ist den richtigen zu nehmen.8-)

Hier mein Vorschlag:
Eine Main Form, der das ganze Managet. D.h. der beinhaltet die Komponenten und lädt nur die DLLs hoch die auch tatsächlich vorhanden sind oder benötigt werden.

[Sir Rufo]

Zitat:

Zitat von hoda (Beitrag 1068216)

Hier mein Vorschlag:
Eine Main Form, der das ganze Managet. D.h. der beinhaltet die Komponenten und lädt nur die DLLs hoch die auch tatsächlich vorhanden sind oder benötigt werden.

Warum dafür eine/die MainForm genommen werden soll erschließt sich aber auch niemandem, da hier ja Funktionen aus DLLs angesprochen werden sollen, und die haben mit der GUI erstmal nix zu schaffen. Warum dann also das an ein GUI-Element verknüpfen bzw. ein GUI-Element zum Verwalten benutzen?

Eine einfache Unit, die diese Verwaltung übernimmt und gut

[hoda]

Zitat:

Warum dafür eine/die MainForm genommen werden soll erschließt sich aber auch niemandem...

Bei einem Planungsprogramm ist ein Frontend (Main Form) zwingend nötig. Wie soll die Interaktion mit dem User ansonsten stattfinden?
Es sei denn, es besteht bereits ein Client-Applikation, in dem man die DLLs hochladen will. Da gebe ich dir völlig Recht, dass dort ein Main Form unnütz ist.

[s.h.a.r.k]

Das war Sir Rufo hier meint ist, dass es mindestens drei Schichten geben soll. Zum einen mal die GUI, das ist klar. Mit irgendwas muss der User ja kommunizieren. Daneben dann eine Schicht, die die ganze Verwaltung der DLLs übernimmt und auch entsprechende Schnittstellen für die GUI und für die DLLs anbietet. Und darunter dann die Schicht mit den DLLs. Hier mal ein kleines Bild:

Code:

    +-------+
    |  GUI   |
    +-------+
        ^
        |
        v
    +--------------+         +-------------------------+         +------+
    |  MANAGEMENT   | <-----> |  Datenbank-Schnistelle   | <-----> |  DB   |
    +--------------+         +-------------------------+         +------+
        ^
        |
        v
    +--------+
    |  DLLs   |
    +--------+

@Sir Rufo: Bitte nicht hauen, wenn ich hier was falsch verstanden habe :mrgreen:

[hans ditter]

okeeeee......
Ich sollte also eine eigene Unit für alle organisatorischen Sachen erstellen?
Das würde also bedeuten, dass ich die GUI hab, die dem Nutzer das Kommunizieren mit meinem Programm erlaubt, dann hab ich die versch. DLLs, die Forms und Methoden exportieren, und eine Unit, die beides miteinander vereint. Hab ich das recht verstanden?

Das würde dann also bedeuten, dass die versch. DLLs (die ja z.B. eine eigene Datasource Komponente brauchen) "ihre" Komponenten zur Laufzeit dynamisch in der "Managementunit" erstellen. Aber wie geht das? Bei einer Unit kann man doch nicht während das Programm ausgeführt wird dynamisch weitere Komponeneten erstellen, oder?

Und bei einer Sache hab ich noch Schwierigkeiten:

Zitat:

Zitat von s.h.a.r.k (Beitrag 1068261)

[...] und auch entsprechende Schnittstellen für die GUI und für die DLLs anbietet.

Was genau meinst du hier mit Schnittstellen?

lg, hans ditter

[hans ditter]

Also, ich hab mir nochmal genauer Gedanken gemacht und versucht, die elementaren Fragen und Aufgaben herauszuarbeiten.

Das ganze soll so aussehen:

Code:

      +-------------------------------------------------+
      |             GUI (Programmoberfläche)             |
      +-------------------------------------------------+
                    /          |             \
                   /           |              \
      +--------------+  +--------------+  +-------------+
      | Planung1-DLL |  | Planung2-DLL |  |Planung3-DLL |
      +--------------+  +--------------+  +-------------+
             |        \ /       |      \ /         |
             |         X         |       X           |
             v         / \       v       / \         v
      +--------------+  +--------------+  +-------------+
      | DB-Planung1  |  | DB-Planung2  |  | DB-Planung3 |
      +--------------+  +--------------+  +-------------+

Im Prinzip soll das Programm versch. Forms der DLLs anzeigen. Die DLLs haben (in den meisten Fällen wohl) eine eigene DB. Jedoch muss es auch möglich sein, dass die DLLs auf die DBs der anderen DLLs zugreifen können. --> eine DB-Komponente ist wohl ausgeschlossen --> DLLs müssen wohl beim starten eine eigene DB-Komponente dynamisch anlegen

Dazu, was die DLLs können müssen:
- muss Mehoden exportieren --> ok
- muss Forms exportieren --> ok
- muss auf (versch.) Datenbanken zugreifen können --> PROBLEM!
-> müsste dynamisch Komponenten erstellen können ???
- muss Einträge im Main Menu vornehmen --> kann ich noch nicht, sollte wohl aber nicht so schwierig sein
- muss eine neue Seite im Page Control anlegen und eigen Form darin anzeigen --> kann ich auch noch nicht, lässt sich aber auch aneignen, denk ich

Die elementarsten Fragen sind damit wohl:
- Wie organisiert / strukturiert man am Besten den Datenbankzugriff?
- Wie lade ich ganze DLLs dynamisch? (vorhanden? -> laden, nicht vorhanden? -> nicht laden)

Zur letzten Frage: Müsste wohl so funktionieren, dass man versucht zu laden. Falls sie geladen wird, ist alles gut, falls eine Fehlermeldung zurückgegeben wird, überspringt man die. Müsste man sich wohl hauptsächlich anschauen, wie man das Programmtechnisch umsetzt.

Soweit zu meinen Gedanken... :D
Hoffentlich könnt ihr mir jetzt noch bessere Tipps geben! :)

Schonmal ein dickes Danke! hans ditter

[DeddyH]

Ich werfe mal als Stichworte LoadLibrary und GetProcAddress in den Raum. Außerdem möchte ich Dir Ollis DLL-Tutorial ans Herz legen.

[hoda]

Hans Ditter warum sollen die DLLs jeweils eine eigene DBs haben?

Die Lösung von s.h.a.r.k ist 1a. Genau das ist auch meine Meinung. Ich kenne das von anderen Softwarelösungen, dass es eine DB gibt (MySQL,Access,SQL Express,usw.) auf den zugegriffen wird. Die DLLs stellen die Module dar, die der Kunde gekauft hat wie z.B. (Marketing, Lohn&Gehalt,usw.).
Wenn der Kunde eine dieser DLLs erworben hat, sieht er im Frontend seinen freigeschalteten Modul.
Ich gehe mal davon aus, dass du hier eher Tabellen meintest:wink:

[Sir Rufo]

Es ist doch völlig Wurst, auf welche DB die DLLs zugreifen (ok, da wo die zugreifen sollen, muss die Struktur da sein).

Aber grundsätzlich stellt mir die DLL einen Funktionstopf zur Verfügung und eine starre Anbindung an die Datenbank X ist ja nicht so schön.

Die Hauptanwendung weiß, wo die DB (Server, Zugangsdaten, Schema) zu finden ist.
In der HA gibt es einen Plugin-Verwalter (eigene Unit), der die vorhandenen Plugins (die DLLs) lädt und initialisiert (Zugangsdaten zur DB). Jetzt kann die HA auf die Funktionen der Plugins zugreifen.

Die Kommunikation unter den Plugins sollte aber über den Plugin-Verwalter gehen (z.B. via CallBack)
denn die Hauptaufgabe bei dem besteht darin, alle vorhandenen Plugins zu kennen und zu verwalten.
Der kann dann auch Plugin A mitteilen, dass es Plugin B gibt und per CallBack zu erreichen ist.

Dadurch erspart man sich die umständliche Verknüpfung der einzelnen Plugins (hier ja DLLs) untereinander, denn das Wesen von Plugins ist ja, dass diese optional und somit nicht vorhanden sein müssen.

Ach ja, wenn es nur eine DB gibt, dann bräuchten die DLLs eigentlich auch keine Informationen zur DB, denn der Zugriff auf selbige könnte ja auch über den Plugin-Manager laufen (siehe Skizze von s.h.a.r.k.)

Wie man schon sieht ist es gerade bei einem solchen Plugin-System exorbitant wichtig viel Zeit in die Planung zu stecken.
Welches Plugin soll welche Funktionen ausführen und welche Informationen werden dafür benötigt.
Wenn das fertig ist, dann kann man entscheiden auf welchem Weg man diese Informationen bekommt (holt das Plugin die Informationen direkt, über einen Callback oder werden diese schon beim Aufruf mitgeliefert)

[Blup]

Im Prinzip geht es doch darum, das alle Teile möglichst unabhängig von einander funktionieren.
Darum würde ich Interface einsetzen.

Zitat:

Dazu, was die DLLs können müssen:
- muss Mehoden exportieren --> ok
- muss Forms exportieren --> ok

Statt dessen sollte ein Interface beim Anwendungskern in einer Interface-Liste registriert werden. Wo immer ein bestimmtes Interface benötigt wird, wird es vom Kern geholt.

Zitat:

- muss auf (versch.) Datenbanken zugreifen können --> PROBLEM!

Verschiedene Datenbanksysteme oder verschiedene Datenbankdateien?
Eigentlich braucht man ja nur die Verbindungsparameter z.B. als Connectstring weiter zu geben.

Zitat:

-> müsste dynamisch Komponenten erstellen können ???

Sollen sie, warum auch nicht?

Zitat:

- muss Einträge im Main Menu vornehmen --> kann ich noch nicht, sollte wohl aber nicht so schwierig sein
- muss eine neue Seite im Page Control anlegen und eigen Form darin anzeigen --> kann ich auch noch nicht, lässt sich aber auch aneignen, denk ich

Das ist Aufgabe der GUI. Die GUI fragt alle beim Anwendungskern registrierten Interface ab und prüft für jedes, ob ein Interface suportet wird, das Informationen zu zusätzlichen Menüpunkten bereitstellt. Diese werden angelegt und mit der Funktion aus dem Interface verknüpft.
Die GUI könnte sich beim Anwendungskern auch als Observer für die registrierten Interface anmelden, um gegebenenfalls auf Änderung reagieren zu können.

Code:

+----------------+    +--------------+--------------+
|                | -- | Interface     | GUI           |
|                |    +--------------+--------------+
|                |    
|                |    +--------------+--------------+
|                | -- | Interface     | Planung1-DLL |
|                |    +--------------+--------------+
| Anwendungskern |    
|                |    +--------------+--------------+
|                | -- | Interface     | Planung2-DLL |
|                |    +--------------+--------------+
|                |    
|                |    +--------------+--------------+
|                | -- | Interface     | Planung3-DLL |
+----------------+    +--------------+--------------+

Man könnte sogar so weit gehn, jeweils eine DLL für die fachliche Logik und eine für die Oberfläche zu dieser Logik einzusetzen.
Dann wäre die Oberfläche komplett austauschbar (z.B. Web-Darstellung), ohne die eigentliche Anwendung zu beeinflussen.

[hans ditter]

Wow, gute Antworten... aber damit bin ich grade überfordert... :oops:

Also, ich hab die Hauptanwendung (HA), die hat eine (?) Komponente für den Datenbankzugriff. Dann hab ich eine Unit, die die gesamte (?) Kommunikation zwischen HA und den DLLs regelt. Dann hab ich noch die DLL, die Informationen (wie z.B. den ConnectionString) preisgibt, und damit den Zugriff auf die Datenbankdatei ermöglicht.

@Sir Rufo:
:?:Aber wie mache ich das mit der Unit? Wie ich damit das Laden und initialisieren der DLL hinbekomme ist mir noch klar. Aber wie mache ich das mit den ganzen exportierten Methoden der DLL? Soll ich die auch nur über die Unit aufrufen? Und wie macht man das dann?
:?:Was bedeutet ein Callback? Callback = zurückrufen? Aber wie hängt das mit der Kommunikation zwischen versch. DLLs zusammen?

:!:Zum Aufbau nochmal: Also, bis jetzt haben alle (es sind bisher nur 2) Module eine eigene Datenbankdatei. Daher müssen die versch. DLLs wohl doch Verbindungsdaten exportieren...

@Blup:
:?:Was genau meinst du mit Anwendungskern? Ich kann mir darunter nicht so richtig was vorstellen...
:?:Und wie in Himmels Namen funktioniert das mit den Interface? Ich hab schon ganz häufig (praktisch immer wenn's um DLLs ging) von diesem Interface gehört, kann mir aber immer noch nicht vorstellen/erklären, wie das funktionieren soll. Kannst du dafür möglicherweise ein Tutorial empfehlen? Und vor allem: Was wäre der Vorteil an einem Interface gegenüber einem Programm ohne Interface?

:?:Eine eher allgemeine Frage hab ich auch noch. Ich schreibe mir jetzt 2 Module: Modul1 und Modul2 und eine HA. Jetzt möchte ich aber in einem halben Jahr, ich habe bis dahin die beiden vorhandenen Module fleißig benutzt, ein weiteres hinzufügen. Was muss ich dann machen? Geht das überhaupt? Wenn ja, kommen da irgendwelche großen Probleme auf mich zu?

Mein Gott, schon wieder so viele Fragen...:oops: Ich freue mich auf eure Antworten!

schneeige Grüße, hans ditter

[Assarbad]

Zitat:

Zitat von DeddyH (Beitrag 1068354)

Ich werfe mal als Stichworte LoadLibrary und GetProcAddress in den Raum. Außerdem möchte ich Dir Ollis DLL-Tutorial ans Herz legen.

Aaaah. Damit willst du mich nur zwingen es endlich zu aktualisieren, oder? :zwinker: War lange geplant, aber es finden sich weder Mitstreiter (trotz SF.net-Projekts als unabhängige Platform) noch Zeit. :stupid:

Das was ich am meisten als Mißverständnis bei der Benutzung von DLLs sehe ist, daß die Leute DLLs oft als eigenständige Programme sehen. Das stimmt natürlich nicht. Aber um das zu verstehen muß man den Zusammenhang zwischen dem Code, einem Prozeß und den Threads in einem Prozeß erstmal begreifen. Da hakt es oftmals.

Ein Prozeß führt keinen Code aus, eine DLL auch nicht. Die DLL (wie auch die EXE) ist Container für Code und der Prozeß Container für Threads ... und die Threads führen den Code (quasi-)parallel (je nach Anzahl CPUs) aus. Im Endeffekt ist es absolut egal ob der Code der ausgeführt wird (sagen wir mal Quicksort) nun im Abbild der EXE oder im Abbild der DLL im Speicher liegt. Dennoch gibt es natürlich Einschränkungen, aber da muß ich auch auf ein leider etwas in die Jahre gekommenes Tutorial von mir verweisen, wie DeddyH auch schon.

Zitat:

Zitat von Blup (Beitrag 1068396)

Im Prinzip geht es doch darum, das alle Teile möglichst unabhängig von einander funktionieren.
Darum würde ich Interface einsetzen.

Ich nehme an du meinst basierend auf IUnknown und Konsorten? Unterstütze ich in dem Fall voll.

Zitat:

Zitat von Blup (Beitrag 1068396)

Das ist Aufgabe der GUI. Die GUI fragt alle beim Anwendungskern registrierten Interface ab und prüft für jedes, ob ein Interface suportet wird, das Informationen zu zusätzlichen Menüpunkten bereitstellt. Diese werden angelegt und mit der Funktion aus dem Interface verknüpft.
Die GUI könnte sich beim Anwendungskern auch als Observer für die registrierten Interface anmelden, um gegebenenfalls auf Änderung reagieren zu können.

Hier würde ich eher noch weiter differenzieren und die Logik dazu welche Interfaces unterstützt werden eine Ebene unter der GUI ansiedeln.

Zitat:

Zitat von Blup (Beitrag 1068396)

Man könnte sogar so weit gehn, jeweils eine DLL für die fachliche Logik und eine für die Oberfläche zu dieser Logik einzusetzen.

Das läßt sich a.) nicht für jeden Anwendungs-/GUI-Typ machen und b.) ist es nicht so clever wie es anfänglich klingt jeweils immer einzelne DLLs anzubieten. Für die Kernkompetenzen der Anwendung kann auch eine DLL mehrere Interfaces anbieten (über COM oder einen Mechanismus der den in COM nachbildet) für Erweiterungen würde ich wiederum mitgehen mit mehreren einzelnen DLLs ...

Zitat:

Zitat von Blup (Beitrag 1068396)

Dann wäre die Oberfläche komplett austauschbar (z.B. Web-Darstellung), ohne die eigentliche Anwendung zu beeinflussen.

Jetzt sind wir wieder beieinander.

[DeddyH]

Zitat:

Zitat von Assarbad (Beitrag 1069020)

Zitat:

Zitat von DeddyH (Beitrag 1068354)

Ich werfe mal als Stichworte LoadLibrary und GetProcAddress in den Raum. Außerdem möchte ich Dir Ollis DLL-Tutorial ans Herz legen.

Aaaah. Damit willst du mich nur zwingen es endlich zu aktualisieren, oder? :zwinker:

Kleiner Wink mit dem Jägerzaun :mrgreen:

[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??? :pale: :shock:

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. :thumb:

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. :idea:

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:

Zitat von hans ditter (Beitrag 1069666)

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... :zwinker: (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

[Bummi]

@hans ditter

Wenn Du Dich mit Interfaces beschäftigen möchtest, würde ich Dir TInterFacedPersistent anstatt TInterfacedObject als Option ans Herz legen wollen.
Die IMHO intransparenete Speicherverwaltung von TInterfacedObject, bzw. darauf basiererend Komponenten fällt damit weg und alles verhält sich etwas mehr wie gewohnt.

[hans ditter]

@Bummi
Danke, werd ich mir merken.

@Marc
Danke für die Links, die les ich mir mal durch. Mal schauen, vielleicht ist mir dann ja schon einiges klarer.
Du hast allerdings Recht: Am Anfang ist das irgendwie alles seeehr unübersichtlich. Vor allem Vererbung ist manchmal sehr komisch... :D

LG, hans ditter

[hans ditter]

Oh mann... ich verstehs einfach nicht :cry: *heul*

Ich hab mir die ganzen Sachen durchgelesen. Dann hab ich versucht, dass ganze selbst mal umzusetzten. Ich hab das Ergebnis rangehängt. Aber es funktioniert überhaupt nicht. Schon beim Start sagt er mir, dass da ein Zugriffsfehler ist.
"...Exception der Klasse EReadError mit der Meldung 'Ungültiger Eigenschaftswert' aufgetreten."
Wenn ich dann auf Fortsetzen klicke:
"...Exception der Klasse EReadError mit der Meldung 'Fehler beim Lesen von Form1.OnCreate: Ungültiger Eigenschaftswert' aufgetreten."
Und dann stürzt das Programm ab... :cry:

Helft mir...bitte!

[MGC]

@Hans Ditter

Kann es sein das die angehängte ZIP-Datei nicht das fertige Projekt enthält?
Du hast nämlich noch keine Klasse in der DLL erstellt, die das Interface nutzt. Desweiteren hast DU keine globale Funktion über die Du Dir das Interface in Deine Anwenung meldest.
Nochdazu hast Du die DLL aus der Hauptanwendung heraus gar nicht in den Speicher geladen.
So funktioniert das nicht.

ich kann nur nochmal empfehlen:

1. Grundlehrgang für Delphi durcharbeiten
2. Tutorial von Olli (assarbad) zum Thema DLLs durcharbeit, dann wird auch Deine gesamte DLL plötzlich komplett anders aufgebaut sein.

Setze Dich dabei bitte auch explizit mit den Themen Klassen und Zeiger auseinander, damit der DLL-Aufruf und die Klassenimplementation auch funktioniert.

Grüsse,
Marc

[hans ditter]

hmm... da hab ich dann wohl grundlegend was falsch verstanden. Ich werd's mir nochmal anschauen und das ganze überarbeiten. Hast du nochmal einen Link für das DLL-Tutorial? Oder findet man das schnell über die Suche?

angenehme Nachtruhe,

hans ditter

[Bummi]

http://assarbad.net/en/stuff/tutorials/dll_tutorial/

[hans ditter]

Ich danke! Les es mir (wenn ich mal wieder Zeit hab :roll:) durch.

[MGC]

@Hans Ditter

Ich habe noch einen kleinen Vorschlag, wie Dir die Realisierung Deines Projekts vielleicht besser gelingt und Du Dir Übersicht verschaffst.
Lege Dir doch ein Projekt als Prototyp an und erstelle alles in verschiedenen Forms udn Units, die Du bereits von anfang an logisch nach Deinem Schichten-Modell anlegst (Form für die GUI, Unit für die Logik der GUI; Datenmodul mit den Datensensitiven Komponenten, Unit für die Logik zum Datenmodul usw.).
Gehe die Anforderungen, die Du an das System stellst durch und plane sie in Klassen ein, die Du wiederum den verschiedenen Schichten zuordnest.
Wenn dieser Prototyp läuft, dann erst beginnst beginnst Du mit der Auslagerung in die DLLs und schreibst (je nach Realisierungs-Strategie) eine Konsolenanwendung (die eigentliche EXE-Datei), die schließlich die DLLs lädt...

Also, kurzgefasst würde ich folgendes Vorgehen vorschlagen:

1. Anforderungen an das zu erstellende System sammeln

2. Die Anforderungen analysieren und daraus zu erstelende Klassen, Objekte usw. ableiten
2.a. Die Realisierungsvorstellungen können dabei in kleinen Mini-Tests ausprobiert werden.
Auf diese Weise sieht man schon sehr schnell, ob und wie ein Grundgedanke sich umsetzen
läßt.

3. Das erstellte Modell in einem oder mehreren Prototypen programmatisch umsetzen
3.a. Hier können ggf. weitere Anforderungen erkennbar werden, die wiederum eingeplant um
umgesetzt werden müssen/können

ODER

3. Umsetzung des Gesamtprojekts in logischen und testbaren Teileinheiten, die später
zusammengefügt werden. (Kann/sollte dennoch mit Prototyping verbunden sein)

4. Fertigstellung des geplanten Systems

Besonders hilfreich wären hierbei auch die Unit-Tests mit DUnit. (Ein Gedankenansatz der später bei Dir mit Sicherheit ganz von allein hinzukommen wird...)

Viele Grüße,
Marc

P.S.: Häng Dich noch nicht zusehr an Dein geplantes Projekt, spiel doch mal ein wenig mit den Grundlagen herum. Schreib kleine Testprogramme, bis Dir die Strukturen für Dein Projekt klar werden.
(z.B.: einfach mal eine Klasse entwerfen; oder in Hinblick auf DLLs: schick doch einfach mal einen einfachen String in eine DLL, verändere ihn dort und sende ihn wieder zurück. Danach baust Du Dein Programm und auch Deine DLL ein wenig aus und wende Dich komplexeren Aufgaben zu.

[hans ditter]

Hm, hört sich interessant an.
Ich glaube, dass werde ich mal versuchen!

Ich weiß, dass ich zu sehr an dem Projekt hänge... man möchte so gerne auch endlich mal was "Großes" entwerfen... :oops:

Ich werd mal versuche, dass ich die Grundlagen nochmal genauer durchgehe und dann mein Projekt in Teilschritten (Teilprogrammen) anfange umzusetzten.

LG, hans ditter

P.S.: Werd mich hier aber trotzdem immer mal wieder melden. Geht schließlich trotzdem nicht von heute auf morgen... :wink:

[hans ditter]

WAHNSINN!! Es hat geklappt!
Ich hab's gestern geschafft eine Anwendung mit einer DLL, einem Interface und zwei Methoden zum Laufen zu bringen. Ich häng sie mal an. Wenn ihr da mal einen kurzen Blick raufwerfen könntet, ob das jetzt so richtig/korrekt/sauber/... programmiert ist?!

Ich danke euch!
LG, hans ditter