Aus DLL auf Hauptprogramm-Funktionalität zugreifen
-
Hallo zusammen,
ich hab ein Programm geschrieben an das weitere Problemlösungen einfach per DLL angedockt werden können.Jetzt möchte ich aber auch aus der DLL auf einige Klassen des Hauptprogramms zugreifen können. Wie kann ich das aber realisieren?
Mein erster Ansatz war, einfach das Header-File einer Testklasse ins DLL Projekt zu kopieren. Dann war schonmal die Klasse mit Methoden bekannt. Natürlich gab es dann aber Linker-Fehler, weil er keine passende implementation hinzubinden konnte. Ich hab einfach mal ein extern for die deklaration gesetzt, aber geholfen hat das nicht wirklich
Kann ich an dieser Stelle irgendwie der DLL mitteilen, garnicht erst nach einer implementierung zu schaun, bzw. dass sich die implementierung in der exe befinden wird ???
Wenn nich werdet Ihr mir wahrscheinlich raten benannte Klassen in DLLs auszulagern und dann in die andere DLL einzubinden oder ?!
Also für software-architektonische Ratschläge wäre ich sehr dankbar.
Philipp
-
Hever schrieb:
Mein erster Ansatz war, einfach das Header-File einer Testklasse ins DLL Projekt zu kopieren. Dann war schonmal die Klasse mit Methoden bekannt.
Wieso kopieren? Wieso nicht einfach includen?
Wenn nich werdet Ihr mir wahrscheinlich raten benannte Klassen in DLLs auszulagern und dann in die andere DLL einzubinden oder ?!
Das wäre eine Möglichkeit.
Oder du schickst eine User-Nachricht an den Mainframe, der dann die gewünschte Funktion aufruft. (Ich glaube, das wäre die sauberste Variante.)
-
estartu schrieb:
Hever schrieb:
Mein erster Ansatz war, einfach das Header-File einer Testklasse ins DLL Projekt zu kopieren. Dann war schonmal die Klasse mit Methoden bekannt.
Wieso kopieren? Wieso nicht einfach includen?
Weil auch andere Personen einfach was hinzuschreiben können und ich dann dazu ein Beispielprojekt rausgeben würde, wo dann auch die Header-Files einiger Klassen bei sind, die Sie verwenden könnten. Daher hab ich die Dateien direkt in ein anderes Projekt kopiert. (Visual Studio .NET)
estartu schrieb:
Oder du schickst eine User-Nachricht an den Mainframe, der dann die gewünschte Funktion aufruft. (Ich glaube, das wäre die sauberste Variante.)
Das ist denke ich nicht so ganz was ich wollte. Ich will schon die Methoden aufrufen, Parameter übergeben und Rückgabewerte verarbeiten....
Wie gesagt ich habe eine DLL und möchte aus der DLL auf Funktionen oder Klassen zugreifen die erst später, wenn Sie im Programm eingebunden wurde, verfügbar sind.
-
Kann ich nicht irgendwie mitteilen, dass es sich bei den Klassen im Hauptprogramm um solche handelt, die auch von "aussen" aufrufbar sind, mit
extern "C++" AFX_EXT_API
oder so?
Und die dann in der DLL entsprechend einbinden und verwenden...
-
Hever schrieb:
Kann ich nicht irgendwie mitteilen, dass es sich bei den Klassen im Hauptprogramm um solche handelt, die auch von "aussen" aufrufbar sind, mit
extern "C++" AFX_EXT_API
oder so?
Und die dann in der DLL entsprechend einbinden und verwenden...
Keine Ahnung, bei mir geht das auch so, ich muss den Header nur includen. Allerdings habe ich MFC-Erweiterungsdlls, vielleicht liegt es daran.
Aber ich tendiere dazu:Wenn nich werdet Ihr mir wahrscheinlich raten benannte Klassen in DLLs auszulagern und dann in die andere DLL einzubinden oder ?!
Was besseres fällt mir bei den Anforderungen nicht ein, sorry.
-
Hallo,
estartu schrieb:
Keine Ahnung, bei mir geht das auch so, ich muss den Header nur includen. Allerdings habe ich MFC-Erweiterungsdlls, vielleicht liegt es daran.
Was meinst du denn mit so? Also das mit extern ?:
extern "C++" AFX_EXT_API
Ich probiers mal aus. Ich hab auch MFC-Erweiterungs DLLs.
Letzteres wollte ich nur etwas ungern verwenden, damit es nicht total unübersichtlich mit den ganzen DLLs wird.
-
Nö, ohne extern. Einfach so.
Zeiger auf die App holen und los. Ohne export/import oder so.
-
Die Idee find ich schonmal Klasse.
Aber klappen tuts leider nicht. An die App komm ich natürlich, caste die App dann zu meiner Tatsächlichen App, aber kann keine Methoden aufrufen. (Siehe unten)
Wie gesagt ich habe zwei Projekte. Einmal das Hauptprogramm und einmal die DLL. Ich hab jetzt die Klasse die ich in der DLL auch verwenden möchte rüberkopiert ins DLL Projekt (MeineKlasse.h).
Dann compiliert natürlich noch alles. Wenn ich nun aber ein Objekt der Klasse erstelle und auf Methoden zugreifen möchte, gibt es Linker-Fehler. "Nicht aufgelöstes externes Symbol", weil er ja keine implementation der Methode finden kann.
Wie hast du dass denn geschafft ???
-
Ich hab jedenfalls nix kopiert.
Also: Ich habe eine Funktion in der App z.B. GetUser.
Der Kopf steht in App.h, der Rumpf in App.cpp und nur da.In der Dll include ich App.h, hole einen Zeiger auf die App (das klappt bei dir ja) und kann dann GetUser aufrufen:
CApp* pApp = (CApp*)AfxGetApp(); pApp->GetUser();
Mehr mach ich nicht, jedenfalls nicht bewusst.
Wenn du unbedingt kopieren willst, musst du wohl oder übel das Cpp mitnehmen, glaub ich.
-
Womit programmierst du denn?
Dann sind bei dir DLL und Hauptprogramm in einem Projekt und dann ist klar, dass er das linken kann, weil die cpp ja im selben Projekt liegt.
Naja dann werde ich wohl dahin gehen, noch eine DLL zu erstellen, und bestimmte Klassen, und Datentypen auslagern. Dann lade ich in der DLL die andere DLL.... hoffentlich wirds nicht notwendig aus der anderen DLL auch noch auf andere Funktionen zurückzugreifen
Das kann ja ne "DLL-Hölle" werden
Trotzdem danke!
-
Ich programmiere mit VC6 und 7.1.
Hever schrieb:
Dann sind bei dir DLL und Hauptprogramm in einem Projekt und dann ist klar, dass er das linken kann, weil die cpp ja im selben Projekt liegt.
Ja, ich habe zig Dlls und eine Exe (also mehrere Projekte) in einem Arbeitsbereich. So ist das schön komfortabel.
-
Ja klar, das feature benutzt ich auch gerne
Aber dann kannst du einfach nen headerfile aus nem anderen Projekt includen ?!
-
Mit einer *.lib Datei würde ich auch nicht weiter kommen ???
-
Hever schrieb:
Ja klar, das feature benutzt ich auch gerne
Aber dann kannst du einfach nen headerfile aus nem anderen Projekt includen ?!
Ja klar.
Von libs habe ich leider keine Ahnung.