DLL soll Methoden der Anwendung aufrufen, welche die DLL gebunden hat

FrodoSix

Ich schreibe gerade ein Anwendung, bei der 2 Objekte verschiedener Klassen (nennen wir sie mal "App" und "Interface") gegenseitig Methoden der jeweils anderen aufrufen können müssen. Soweit ja kein Problem. Allerdings sollen die Klassen nicht in einem Projekt vereint sein, sondern die Klasse "App" soll in einer Applikation vorhanden sein und die Klasse "Interface" zum Beispiel in einer DLL. Ich habe es soweit geschafft, dass die Klasse "App" auf die Klasse "Interface" zugreifen kann (einfach durch Einbindung der "Interface-DLL" in die Applikation). Der umgekehrte Weg macht mir aber Schwierigkeiten (also Zugriff auf die "App"-Klasse in der Applikation von der "Interface-Klasse" in der DLL aus).

Ich würde mal vermuten, dass die Kommunikation mit einer DLL, die in eine Applikation eingebunden wird nur in einer Richtung möglich ist (korrigieren, falls das falsch ist). Welchen Ansatz muss ich sonst wählen um das gewünschte (also Methodenaufrufe in beiden Richtungen) zu erreichen?

TGGC

FrodoSix schrieb:

Ich würde mal vermuten, dass die Kommunikation mit einer DLL, die in eine Applikation eingebunden wird nur in einer Richtung möglich ist (korrigieren, falls das falsch ist).

Korrigier. Rufe einfach auf.

Bye, TGGC (Dem beste BdT)

FrodoSix

TGGC schrieb:

Korrigier. Rufe einfach auf.

Wenn's so einfach wäre, würd ich nicht fragen. Aber vielleicht hab ich mich auch nicht ganz klar ausgedrückt... also nochmal.
Ich hab eine DLL mit einer Klasse, die diverse Methoden enthält:
[cpp]class __declspec(dllexport) OsInterface {
private:
// Pointer auf ein Objekt der Klasse "App"
class App * appPointer;

public:
// Konstruktor: das App-Objekt, das dieses Objekt erstellen will, übergibt einen Zeiger auf sich selbst
OsInterface(App * pointerToAppObject) {
appPointer = pointerToAppObject;
}

void oiMtehode() {
appPointer->appMethode2CallFromOsInterface(); // Das hier geht nicht
}

int methode2CallFromApp() {
// Tue irgendwas
}
}[/cpp]

Weiterhin habe ich meine Anwendung (exe), die diese DLL einbindet. Die Anwendung besteht u.a. aus der Klasse App:

class App {
private:
   // Pointer auf ein Objekt der Klasse OsInterface
   OsInterface * oi;

public:
   void createOsInterface() {
      // Dem OsInterface-Objekt wird ein Zeiger auf dieses "App"-Objekt übergeben
      oi = new OsInterface(this);
   }

   void appMethode() {
      oi->methode2CallFromApp();  // Das hier geht
   }

   void appMethode2CallFromOsInterface() {
      // Tue irgendwas
   }
}

Da ich die DLL in die Applikation eingebunden habe, kann ich über den Zeiger 'OsInterface * oi' der Klasse App die Methoden des OsInterfaceObjekts aufrufen.
Nun würde ich gerne auch, dass das OsInterface-Objekt Methoden aus "App" aufgerufen kann.
Ich dachte, dass ich das über den Zeiger App * appPointer machen könnte. Aber wenn ich das hier versuche bekomme ich beim Compilieren der DLL die Meldung, dass ein externer Verweis auf die Methode "appMethode2CallFromOsInterface()" fehlt. Ich wüßte nicht wie ich den Verweis vom Exe-Projekt in dem DLL-Projekt bekannt machen könnte.

Noch mal einfacher gesprochen...
Ich will, dass sich ein Objekt von "App" und ein Objekt von "OsInterface" gegenseitig "kennen" und ähnlich wie beim Handshake abwechselnd ihre Methoden aufrufen können.

TGGC

FrodoSix schrieb:

Aber wenn ich das hier versuche bekomme ich beim Compilieren der DLL die Meldung, dass ein externer Verweis auf die Methode "appMethode2CallFromOsInterface()" fehlt. Ich wüßte nicht wie ich den Verweis vom Exe-Projekt in dem DLL-Projekt bekannt machen könnte.

So wie immer.

Bye, TGGC (Dem beste BdT)

FrodoSix

TGGC schrieb:

So wie immer.

Und was heisst das konkret? Falls Du meinst, dass ich die Header-Datei einbinden soll... das hab ich gemacht. Geht aber trozdem nicht... siehe oben.

estartu

Eigentlich soll eine Dll ihre Anwendung ja nicht aufrufen, weil man die sonst nicht in anderen Anwendungen benutzen kann.

Wie wäre es denn mit Nachrichten an die Anwendung schicken?

Dann kannst du dir das Includen und das alles sparen.

Hier ist mein Fall:

BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)
	//{{AFX_MSG_MAP(CMainFrame)
//...
	//}}AFX_MSG_MAP
	ON_MESSAGE(WM_UPDATE_TEXTE, OnUpdateTexte)
END_MESSAGE_MAP()

LRESULT CMainFrame::OnUpdateTexte(WPARAM wParam, LPARAM pParam)
{
	CBasisDoc* pDoc = (CBasisDoc*)(wParam);
	ASSERT(pDoc);
//...
	return 0;
}

WM_UPDATE_TEXTE ist in der Dll deklariert, so ist es überall bekannt.

Ups, wie man das aufruft sollte ich wohl auch noch schreiben...

AfxGetMainWnd()->SendMessage(WM_UPDATE_TEXTE, (WPARAM)this);

FrodoSix

estartu_de schrieb:

Eigentlich soll eine Dll ihre Anwendung ja nicht aufrufen, weil man die sonst nicht in anderen Anwendungen benutzen kann.

Es ist vorgesehen, dass die "OsInterface"-Klasse aus der DLL ausschliesslich nur mit Objekten der "App" Klassen kommuniziert. Das heisst egal in welche Applikation die DLL eingebunden werden soll: eine Klasse App muss dort auf jeden Fall immer vorhanden sein. Von daher ist der Einwand nicht von Bedeutung fuer meinen Fall.

Das mit den Nachrichten muss ich mal ueberdenken, ob ich dass so einsetzen kann - danke erstmal fuer den Tip. Bin aber nicht ganz sicher (der Grund ist, dass ich das Klassenmodell eines bestimmten Standards umsetze und deswegen nicht gross davon abweichen kann).

Prinzipiell koennte ich die App-Klasse auch mit in die DLL nehmen. Aber vom Konzept her gehoert sie in die Applikation

Wenn das mit Exe <-> DLL Bindung zu komplizieret ist, gaebe es andere Moeglichkeiten das einfacher hinuzbekommen (zum Beispiel COM oder aehnliches)?

FrodoSix

estartu_de schrieb:

Eigentlich soll eine Dll ihre Anwendung ja nicht aufrufen, weil man die sonst nicht in anderen Anwendungen benutzen kann.

Es ist vorgesehen, dass die "OsInterface"-Klasse aus der DLL ausschliesslich nur mit Objekten der "App" Klassen kommuniziert. Das heisst egal in welche Applikation die DLL eingebunden werden soll: eine Klasse App muss dort auf jeden Fall immer vorhanden sein. Von daher ist der Einwand nicht von Bedeutung fuer meinen Fall.

Das mit den Nachrichten muss ich mal ueberdenken, ob ich dass so einsetzen kann - danke erstmal fuer den Tip. Bin aber nicht ganz sicher (der Grund ist, dass ich das Klassenmodell eines bestimmten Standards umsetze und deswegen nicht gross davon abweichen kann).

Prinzipiell koennte ich die App-Klasse auch mit in die DLL nehmen. Aber vom Konzept her gehoert sie in die Applikation

Wenn das mit Exe <-> DLL Bindung zu komplizieret ist, gaebe es andere Moeglichkeiten das einfacher hinuzbekommen (zum Beispiel COM oder aehnliches)?

FrodoSix

Es ist vorgesehen, dass die "OsInterface"-Klasse aus der DLL ausschliesslich nur mit Objekten der "App" Klassen kommuniziert. Das heisst egal in welche Applikation die DLL eingebunden werden soll: eine Klasse App muss dort auf jeden Fall immer vorhanden sein.

Das mit den Nachrichten muss ich mal ueberdenken, ob ich dass so einsetzen kann - danke erstmal fuer den Tip. Bin aber nicht ganz sicher (der Grund ist, dass ich das Klassenmodell eines bestimmten Standards umsetze und deswegen nicht gross davon abweichen kann).

Prinzipiell koennte ich die App-Klasse auch mit in die DLL nehmen. Aber vom Konzept her gehoert sie in die Applikation

Wenn das mit Exe <-> DLL Bindung zu komplizieret ist, gaebe es andere Moeglichkeiten das einfacher hinuzbekommen (zum Beispiel COM oder aehnliches)?

estartu_de schrieb:

Eigentlich soll eine Dll ihre Anwendung ja nicht aufrufen, weil man die sonst nicht in anderen Anwendungen benutzen kann.

Wie wäre es denn mit Nachrichten an die Anwendung schicken?

Dann kannst du dir das Includen und das alles sparen.

Hier ist mein Fall:
BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)
	//{{AFX_MSG_MAP(CMainFrame)
//...
	//}}AFX_MSG_MAP
	ON_MESSAGE(WM_UPDATE_TEXTE, OnUpdateTexte)
END_MESSAGE_MAP()

LRESULT CMainFrame::OnUpdateTexte(WPARAM wParam, LPARAM pParam)
{
	CBasisDoc* pDoc = (CBasisDoc*)(wParam);
	ASSERT(pDoc);
//...
	return 0;
}
WM_UPDATE_TEXTE ist in der Dll deklariert, so ist es überall bekannt.

estartu

Von COM habe ich keine Ahnung, sorry.

Ich mach das halt mit Nachrichten, weil es so schön funktioniert.