Wie modularisiertes Programm realisieren? (Plugins ?)

[TPok]

Hallo,

ich habe demnächst ein Projekt vor und weiß nicht recht, wie ich es realisieren soll. Deshalb bitte ich um Anregungen, die mir (hoffentlich) den nötigen Geistesblitz verschaffen.
Ich habe mehrere Reports in Crystal Reports erstellt und möchte für diese einen modularisierten Viewer erstellen.
Das Hauptprogramm soll die Funktionen für Vorschaufenster, Druck, Export, etc. enthalten. Weiterhin soll es pro Report ein Modul geben, das eine Oberfläche mit Eingabefeldern für Parameterwerte und ggf. ein bißchen Prüflogik für die Eingaben enthält.
Ich könnte ja alles in eine Anwendung packen, müßte dann aber bei jedem neuen Report alles neu compilieren. Viel lieber würde ich mit jedem Report ein zusätliches Oberflächenmodul mitliefern, ins richtige Verzeichnis kopieren und fertig.

Nur wie läßt sich sowas ohne großen Aufwand realisieren?

Besten Dank,
TPok

[Dani]

Hi!

Ich versuche mich zur Zeit am selben Problem. Ich glaube mit Delphi ist das dank der VCL so gut wie nicht zu realisieren. Jedenfalls nicht ohne "zufällig" auftretende Zugriffsverletzungen, ungültige Zeigeroperationen usw. Oder die Lösung ist zu wertvoll, als dass man sie einfach preisgibt. Keine Ahnung.

Vielleicht hilft das ja ein bischen weiter:

http://www.delphipraxis.net/internal...807&highlight=

http://delphi.about.com/library/weekly/aa012301a.htm

http://www.cppbuilderdevjournal.com/...s_in_a_DLL.htm

http://www.delphipraxis.net/internal...ct.php?t=35909

[Hansa]

Zitat:

Zitat von Dani

... Ich glaube mit Delphi ist das dank der VCL...

Das ist ja wieder mal toll. 8) Was soll da nicht gehen ? :shock: Ich würde eine INI-Datei verwenden und fertig.

Zitat:

Zitat von Dani

...Oder die Lösung ist zu wertvoll, als dass man sie einfach preisgibt...

Wer wird Millionär ? :mrgreen:

[supermuckl]

es gibt doch die möglichkeit, ganze klassen usw (runtime) in eine datei zu speichern!
die würde ich dann einfach "laden" und platzieren auf nem form oder wie auch immer was du da dynamisch haben willst ?!

[Dani]

Zitat:

Zitat von Hansa

Ich würde eine INI-Datei verwenden und fertig.

Also wenn du es schaffst, ein Formular inklusive aller Methoden, Daten, Controls usw. in einer Ini-Datei zu speichern und wieder auszulesen, dann bin ich echt baff :mrgreen:

Zitat:

Zitat von TPok

Weiterhin soll es pro Report ein Modul geben, das eine Oberfläche mit Eingabefeldern für Parameterwerte und ggf. ein bißchen Prüflogik für die Eingaben enthält.

Zitat:

Zitat von supermuckl

es gibt doch die möglichkeit, ganze klassen usw (runtime) in eine datei zu speichern!

Yep, und wie trennt man diese Klassen so von der Hauptanwendung ab, dass sie nicht fest in diese hineincompiliert werden? Packages? Versucht mal von der Hauptanwendung aus auf die Formklasse im Package zuzugreifen, nachdem es geladen wurde. Da geht selbst nach RegisterClass(...) nix ausserhalb der im Package befindlichen Units. RegisterClass funktioniert leider nicht "Application-wide".

[Hansa]

Zitat:

Zitat von Dani

Also wenn du es schaffst, ein Formular inklusive aller Methoden, Daten, Controls usw. in einer Ini-Datei zu speichern und wieder auszulesen, dann bin ich echt baff :

Na klar geht das, mit Methoden usw. müßte man sich allerdings mal was überlegen. :mrgreen: Das Problem an sich ist jedenfalls keins.

[Dani]

Zitat:

Zitat von Hansa

Das Problem an sich ist jedenfalls keins.

Öhm, was genau ist kein Problem? Sorry, falls ich etwas verpeilt wirke, aber ist das jetzt ironisch gemeint oder dein Ernst? %-)

Wenn ich es richtig verstanden habe, möchte TPok ein Formular im Designer erstellen, die eingegebenen Daten überprüfen lassen und eine Schnittstelle zwischen Anwendung und Oberflächenmodul haben. Und dafür würdest du INI Dateien nehmen?

[supermuckl]

da fällt mir nurnoch DLL ein

[Hansa]

Das ist schon mein Ernst. 8) Ohne genaue Kenntnis des Problems läßt sich aber nicht viel sagen. INI Datei ist eventuell zu wenig, aber wie gesagt : keine größeren Probleme.

[supermuckl]

naja wenn er so viele unterschiedlichen datentypen dem kunden in form einer datei übergeben will usw
dann is dll doch so ziemlich das günstigste ?!
kann man ganze forms rein ballern usw und muss keine großartigen dynamischen oberflächen aufbauten bauen :)

//edit

ausserdem können da die speziellen proceduren gleich mit rein und müssen nicht in die hauptapplication integriert werden
so sind auch updates schnell und einfacher möglich

[Tonic1024]

Hi

Ich habe eine Datenbankanwendung geschrieben, die dies problem etwas so gelöst hat:



Ein Hauptmodul, von dem Alle anderen Module verwaltet werden (Laden, Ansteuern, Updaten, Bildschirmausgabe, Drucken etc).

Eine (fast) belibige Zahl von Rechenmodulen (non VCL), die die Daten aus der Datenbank auswerten je nach Aufgabe, und im Hauptmodul auf dem Bildschirm anzeigen. Die Module werden nach Auswahl des Users dynamisch geladen (DLL).

Und eine feste Zahl von System-Modulen. Formulare, die aus einer DLL geladen werden und in der Datenbank eine spezielle Aufgabe erfüllen.



Wenn dir das System helfen könnte wär ich gern bereit dir das näher zu erläutern und mit Codeschnipseln auszuhelfen...

cu

Tonic

[Icemanemp]

Wie wärs mit Com-DLLs ist noch schöner also dein Plugin bzw. Programmmodule als Comserver-DLL erstellen und dann einfach von der Anwendung aus aufrufen! Oder einfach in normale DLLs packen... mit persönlich gefällt aber COM besser.

[Dani]

Der DP-Hint zu "BPL" sagt eigentlich schon das meiste :|

[michael.kaufmann]

hallo,

plugins sind sehr sehr sinvoll wenn man eine flexible Anwendung schreiben will!!!!!!!!
ich selbst schreibe eigentlich in die exe nur noch das aller nötigste und alles andere werden in dlls und in packages ausgelagert.
recht schön und gut das funktioniert auch das die exe eigentlich nichts weiss außer das es irgend welche dlls bzw package laden soll.
dies geht sehr gut über zwb. Jedi Plugin (verwende ich für packages)

bei dlls habe ich es so gemacht das ich gewisse einstiegspunkte festlege / verzeichniss und sie dann bei laufzeit lade.
so fallst du genauere infos benötigst melde dich einfach.

[TPok]

Hallo,

danke für die vielen Antworten.
Das Stichwort DLL hört sich schonmal recht gut an. Da ich sowas noch nie gemacht habe, werde ich mir erstmal das DLL-Tutorial dieser Seite zur Brust nehmen und damit etwas rumspielen.
Sobald ich dann stecken bleibe, werde ich mich mit konkreten Fragen wieder melden.

@Tonic1024:
Dein beschriebenes Konzept, trifft so ungefähr meine Vorstellungen. Ich werde mich ggf. an dich wenden, wenn ich konkrete Fragen habe. Vorallem an der Schnittstelle zwischen EXE und DLL wird es wohl haken, das ahne ich jetzt schon. Mal schaun...

@Icemanemp:
Com-DLLs... Also gelesen hab ich den Namen schonmal, aber dann wirds dunkel. Gibt's dazu irgendwo Info's, Tutorials, etc.? Irgendwas um mir die Materie näher zu bringen?

@michael.kaufmann:
Bis jetzt hab ich immer versucht ohne Jedi-VCL auszukommen. Weiß auch nicht warum. Wohl, weil die EXEn jetzt schon groß genug sind. Ich hab im Netz aber keine Infos zu Jedi Plugin finden. Kannst du mir dazu bitte etwas Input geben? Vorteile gegenüber DDL, etc.

Danke,
TPok

[supermuckl]

com dlls kann ich nur abraten

1. portieren auf andere betriebssysteme geht nicht bzw ist nur schwer möglich
2. bist du auf die com schnittstellen angewiesen.. und wenn die sich malwieder bei ner neuen windoof version ändern musst du mitmachen
3. com kann fehleranfällig sein und dann kriegst du bei der fehlersuche graue haare weil du nicht alles transparent debuggen kannst

also am besten reine DLLs und gut ist.. eine universelle schnittstelle für all deine sachen und dann brauchste nurnoch die DLLs proggen :)

schau aber das du gleich alles erschlägst an schnittstellen zwischen hostanwendung und DLL damit du nich später mal ne neue hostanwendung ausliefern musst nur weil ne schnittstelle gefehlt hat oder falsch war usw.. also planung ist da sehr wichtig

[michael.kaufmann]

Hallo,
die vorteile von Packages sind
wenn du objecte übergibtst brauchst du die bormml nicht mit zu installieren.

Packages sind ja auch nur in prinzip dlls.

Exe zu groß liegt darin das du alles nur in eine EXE reincompilierst bei mir sind meistens die exe files 500k
groß

die Jedi Plugin kann auch mit dll umgehen. sie ist ein anhaltspunkt und da du dich ja mit dlls und packages nicht so gut auskennst kannst du dir diesen sourcecode ja ansehen und davon lernen .