Suche Lösung für folgendes Problem:
"Hauptprogramm" soll eigentlich nur kleine eigenständige Programme (Module) "verwalten".
D.h. bei Start nur mainframe. Die Module liegen in einem definierten Verzeichnis. Bei z.B. "Modul laden" soll dieses Verzeichnis nach (neuen) Modulen durchsucht werden, die verfügbaren angezeigt - (möglichst mit Beschreibung / Vorschau / etc.) - und bei Auswahl im clientbereich des Hauptfensters laufen. Und jedes Modul möglichst nur als ein file.

Die Programmmodule sollten also ständig erweiterbar und nur durch Kopieren in das entsprechende Verzeichnis erkannt werden.

Bin für jeden hint dankbar
oli

P.S. Noch toller wäre ja - komplette Verwaltung im Hauptprogramm. D.h. neue Module als plugin im mainframe (menueeintrag) - die Namensverwaltung und Hierarchie-Ordnung sollte im Hauptprogramm verwaltet werden - aber eventuell/natürlich auch im module-file hinterlegt sein- so dass dieses beim nächsten Start weiss wohin es gehört (oder über registry ?).

Na ja - in jedem Fall
HEEEEEEEEELP ME PLEASE
oli

- Du definierst in deinem Hauptprogramm eine Klasse "CPlugin" mit virtuellen Funktionen wie OnLoad(), TuDies(), TuJenes(), etc
- Jedes Plugin ist eine Dll, in der du eine Unterklasse von CPlugin schreibst, die aus der Dll exportiert wird (class __declspec(dllexport) Plugin1 ...)
- zusätzlich enthält jede Plugin-Dll eine exportierte Funktion wie GetPlugin, die ein Objekt der Pluginklasse als CPlugin-Zeiger zurückgibt.
- Im Hauptprogramm durchsuchst du dann das Plugin-Verzeichnis nach allen DLLs, öffnest diese mit LoadLibrary, holst dir dann mit GetProcAddress den Funktionszeiger auf GetPlugin und läßt dir dann von dieser Funktion ein CPlugin-Objekt erzeugen
- und schon hast du ein Objekt aus einer DLL geladen

Die Verwaltung im Hauptprogramm kann etwa so ausschauen, daß du per Timer regelmäßig das Verzeichnis nach neuen DLLs untersuchst oder dem Benutzer einen Dialog zeigst, in dem er auswählen kann, welches Plugin geladen werden soll.

Wenn das etwa deinen Vorstellungen entspricht kann ich es noch etwas detaillierter erklären. Allerdings kommst du damit nicht sehr weit, wenn die Plugins in jeder Sprache geschrieben werden sollen. An dem Problem sitze ich gerade, die meisten meiner Plugins werden von anderen Leuten in VB oder Delphi geschreiben. Dafür versuche ich mit gerade etwas mit COM zusammenzubasteln, bin aber noch nciht allzuweit um dazu viel sagen zu können...

Schonmal eine Klasse, welche zur Laufzeit geladen wird, exportiert ?

Warum sollte man eine Klasse exportieren wenn man sowieso eine Funktion exportiert die einen Klassenzeiger zurückgibt?

Warum sollte man in der DLL eine "Unterklasse" machen wo sich die Hauptklasse im Hauptprogramm befindet ?

Per Timer würde ich ein Durchsuchen eines Verzeichnisses auf Änderungen der Files nicht starten. Ob sich was ändert weiß am besten das BS da es die Änderungen ja vollzieht.

class CPlugin {
public:
    virtual void OnLoad(void) = NULL;
    ...
};

Beim Laden der Plugins würde ich auch eher den Benutzerdialog vorziehen. Die Entscheidung, welche Plugins geladen werden sollen, sollte soweiso beim Benutzer liegen (naja, kommt auch etwas auf die Anwendung an)

...war wohl nicht die Lösung - war aber vielleicht auch nicht die tollste Beschreibung für meine Frage / Problem.

Ihr müsst Euch das so vorstellen (Vergleich):

Z.B. bekommt man in MSWord bei "Datei Neu" eine Auswahl an Vorlagen (Brief, Fax, etc...) mit Vorschau. Die Vorlagen stehen ja auch in einem bestimmten Ordner und wenn man neue Vorlagen erstellt hat, stehen die eben auch zur Auswahl.

Genau so soll es bei mir funktionieren - nur dass es sich statt Vorlagen um eigenständige Programme handelt, welche dann im clientbereich des Hauptfensters laufen.
Und wenn möglich sollten sich dann bei Auswahl eines Programmes eben Menü-einträge / Buttons im Hauptfenster "einklinken" (das hatte ich mit "plugin" gemeint).

DLL ok. - aber ich möchte eine Vorschau / Beschreibung VOR der Auswahl angezeigt bekommen ohne alle dlls vorher komplett zu laden.

geht das ? - bestimmt ja !! - aber wie ???
mfg + thanx
Oli

Das läßt sich mit der MFC halbwegs brauchbar machen (gibt auch Samples dazu).

Um deine ,lkkmjiiiii (<-- kleiner tip von meiner Katz) "im verzeichnis-suchen" - Aktivierung zu ermöglichen, müßtest du an der Aktivierungsschnittstelle ein bißchen rumbasten, deine Active Document - Server müßten zumindest eine zusätzliche DLL-Funktion exportieren, die die verfügbaren CoClasses auflistet.

Hm... Ich fürchte ich hab' dich jetzt total verwirrt, oder?

Die andere Variante wäre natürlich, alles selbst zu erstellen...

...und da der erste Stolperstein:
Beim Starten der MFC-Container-App (vom Assistenten generiert) bekomme ich Fehlermeldung: "Debug Assertion Failed".
Als Release-Version (logischerweise) läuft es.
[...is it a bug or a feature ?]

Ich bin jedenfalls grad auf der Suche des Problems.
Wenn einer weiss warum und wieso, und mir die Suche verkürzen wollt, Danke schon mal vorab.

mfg
oli

Es kann doch nicht wirklich sein, dass ein Anwendungsgerüst ohne nähere Hinweise auf wieso weshalb und warum einen debug fehler ausgibt.

Es kann doch nicht wirklich sein, dass ein Anwendungsgerüst ohne nähere Hinweise auf wieso weshalb und warum einen debug fehler ausgibt

macht's auch normalerweise nicht....

Was, und wo? Und wie hast du die App erstellt?