ich hatte es mir an Anfang einfach vorgestellt:
Ich erstelle eine MFC DLL, binde eine Resource (DIALOG) ein,
und lasse diesen Dialog aus dem Konstruktor der DLL laden.
ich benutzte dazu das Beispiel, welches hier im forum schon oft
empfohlen wurde "dlldialog" und habe den code nur soweit umgeändert dass
nicht die Testumgebung den Dialog lädt sondern die DLL selber:

#include "stdafx.h"
#include <afxdllx.h>
#include "mcDlg.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif

static AFX_EXTENSION_MODULE DlldialogDLL = { NULL, NULL };

extern "C" int APIENTRY
DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
    .	
    .
    .
    .

	CmcDlg* m_pDlg = new CmcDlg;
	m_pDlg->Create(IDD_DIALOG1);
	m_pDlg->ShowWindow(SW_SHOW);

	return 1;   // OK

}

->tja scheiße, so gehts nichts, beim ausführen kommt ein Assertion Failed.
hab's auch schon mit AFX_MANAGE_STATE versucht, das geht auch nicht.

Mein Problem ist, ich muss ein PlugIn schreiben, hab also auf das Host-Programm keinen Einfluss mehr, kann es also nicht so realisieren das der Host den Dialog lädt.
Die DLL muss dies von sich aus tun, sobald sie vom Host-Prog geladen wird.

Bin für jeglliches Feedback dankbar!

Gruss
Artur

HRESULT TTapiManager::CreateDlg()
{
  HRESULT nRet = S_OK;

  HINSTANCE hinst = ::AfxGetResourceHandle();

  ::AfxSetResourceHandle(GetBPhoneInstance());

  //init the recieve dlg for incoming calls
  m_pDlg = new TapiRecieveDlg();

  if(m_pDlg->Create(IDD_RECIEVE_DLG))
  {
	m_pDlg->SetinTray();

	//set the reciever in the event interface
	m_pEventHandler->SetReciever((TTapiCallInterface*)m_pDlg);
  }
  else
  {
	delete m_pDlg;
	m_pDlg = NULL;

	nRet = FAILED_TO_INIT_DLG;
  }

  ::AfxSetResourceHandle(hinst);

  return nRet;
}

Also GetBPhoneInstance() liefert mir nur die Instance zurück die ich bei dllmain erhalten habe, also kannst du diese ja gleich benutzen. Einen Versuch ist es wert.

m_pDlg->Create(IDD_DIALOG1); 
    m_pDlg->ShowWindow(SW_SHOW);

stürtzt es nicht ab, hab dann aber auch keinen sichtbaren dialog.
ich hatte für das ganze auch schon eine extra klasse gemacht und die funktion von einer ganz anderen stelle als der main aufgerufen, ergebnis was das gleiche.
ich werde mal gleich am montag deine lösung genauer angucken und ausprobieren.

gruss
artur

MfG Spacelord

1. was genau macht bei dir GetBPhoneInstance() und wie sieht die funktion aus? ich hab stattdessen immer hinst eingesetzt, das scheint falsch zu sein

2. SetinTray() , meine Dialogklasse hat diese Methode garnicht, hast du da selber was verändert? oder liegt es am .Net 2003, ist das etwas anderst?

3. m_pEventHandler->SetReciever((TTapiCallInterface*)m_pDlg) , was genau wird hier gemacht?

4. ich hab irgentwo auf msdn hilfeseiten gelesen dieser assertion fail kommt nur bei modalen dialogen vor, von wegen bei mir kommt er aber auch bei nicht modalen dialogen vor. weiter stand da, es rührt daher wenn das host-programm nicht mit mcf programmiert wurde. das kann ich ja nicht wissen, ich hab das host-programm ja nicht gemacht ich hab auch keinen zugriff auf den source-code. ich muss ein plugin schreiben.

sorry, wenn ich mich evt. blöd anstelle aber ich weiss es nicht besser. vielleicht mach ich etwas grundlegendes falsch. zu faul bin ich nicht, ich hab schon so ziemlich alle beiträge gelesen die mit dll & co zu tun haben, aber ich krieg diesen fehler nicht weg!

hab mich jetzt ein mit den beispielen auseinadergesetzt. bin aber noch zu keiner funktionierenden lösung gekommen. das beispiel auf codegure funktioniert bei mir leider auch nicht.
zu stalin's beispiel hab ich noch folgende fragen, da ich es nicht hingekriegt hab es zu implementieren:

1. was genau macht bei dir GetBPhoneInstance() und wie sieht die funktion aus? ich hab stattdessen immer hinst eingesetzt, das scheint falsch zu sein

Hab ich schon gesagt. Sie gibt mir nur die HINSTANCE von der dllmain-Funktion zurück. Ich speicher die halt in einem Objekt.

feisX schrieb:

2. SetinTray() , meine Dialogklasse hat diese Methode garnicht, hast du da selber was verändert? oder liegt es am .Net 2003, ist das etwas anderst?

3. m_pEventHandler->SetReciever((TTapiCallInterface*)m_pDlg) , was genau wird hier gemacht?

Brauchst du nicht und hast du nicht, da ich die Funktionen bzw. Klassen selber geschrieben habe. Machs doch mal so:

extern "C" int APIENTRY
DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
	// Entfernen Sie dies, wenn Sie lpReserved verwenden
	UNREFERENCED_PARAMETER(lpReserved);

	if (dwReason == DLL_PROCESS_ATTACH)
	{
		TRACE0("YYYY.DLL Initializing!\n");

		// One-Time-Initialisierung der Erweiterungs-DLL
		if (!AfxInitExtensionModule(YyyyDLL, hInstance))
			return 0;

		new CDynLinkLibrary(YyyyDLL);
/*YyyyDLL heißt meine Dll, 
hier muss der Name deiner Dll rein rein 
aber das wird ja eh vom Studio alles gemacht, 
also nicht editieren sondern nur anschließende Zeilen bis einschließlich AfxSetReosurceHandle(...) einfügen.*/

		HINSTANCE hinst = ::AfxGetResourceHandle(); 

		::AfxSetResourceHandle(hInstance); 

		CmcDlg* m_pDlg = new CmcDlg; 
	         m_pDlg->Create(IDD_DIALOG1); 
		m_pDlg->ShowWindow(SW_SHOW); 

		::AfxSetResourceHandle(hinst); 

	}
	else if (dwReason == DLL_PROCESS_DETACH)
	{
		TRACE0("YYYY.DLL Terminating!\n");
		// Bibliothek vor dem Aufruf der Destruktoren schließen
		AfxTermExtensionModule(YyyyDLL);
	}
	return 1;   // OK
}

nee, so ähnlich hab ich das gestern auch noch hingekriegt wie dein zweites beispiel. hab es heut morgen aber trotzdem nochmal 1:1 getestet. der assertion fail kommt trotzdem beim ausführen. das problem wird wohl an einer ganz anderen stelle liegen

weiss den keiner was da faul ist???

Du schreibst, dass du mehrere Assertions bekommst - mach doch mal eine Liste:
Was wird mit welchem Kriterium bemeckert? <-> Welchen Wert hat meine Variable an der Stelle?

Manchmal ist es ganz hilfreich, sich den Callstack raufzuarbeiten und mal in den anderen Funktionen zu suchen, was da nicht passen könnte.

PS: Sei mir nicht böse, aber die Frage muss sein: Kennst du denn den ASSERT Befehl? Weisst du, wann und warum er eingesetzt wird?

also zunächst mal deine letzte Frage. Nein ich hab kein Plan was ein ASSERT befehl ist. Was genau macht er?? Ich bin unerfahren im programmieren, bin jetzt im Praxissemester und hab eine für meine Verhältnisse recht anspruchsvolle Aufgabe erhalten. Die ich lösen werde! Egal wie

Der 1. Fehler in afxwin1.inl Line26 siht so aus: klicken

die Code Zeilen sind diese hier:

_AFXWIN_INLINE HINSTANCE AFXAPI AfxGetResourceHandle()
	{ ASSERT(afxCurrentResourceHandle != NULL);
		return afxCurrentResourceHandle; }

Wenn ich Ignore drücke, sieht der nächste Fehler genauso aus, nur in Line23:

_AFXWIN_INLINE HINSTANCE AFXAPI AfxGetInstanceHandle()
	{ ASSERT(afxCurrentInstanceHandle != NULL);
		return afxCurrentInstanceHandle; }

Der 3. ist ebenfalls in Line23 und der 4. ist in Line29, hier kommt schon der Dialog der Host-Progs:

_AFXWIN_INLINE void AFXAPI AfxSetResourceHandle(HINSTANCE hInstResource)
	{ ASSERT(hInstResource != NULL); afxCurrentResourceHandle = hInstResource; }

nachdem ich den 4. ignoriere wird auch schon der zweite Dialog um den es sich hier handelt geladen.

Ich weis nicht was für'n Inhalt in den zu prüfenden Variablen steht, wie finde ich das raus? Und wie prüfe ich den Callstack?

Aber eine grobe Zusammenfassung auch hier:

ASSERT ist ein Makro, das nur im Debugmodus etwas macht (im Releasemodus ist es nix) - nämlich prüfen, ob die in den Klammern stehende Bedingung erfüllt ist. Wenn sie nicht erfüllt ist (der Vergleich liefert FALSE), wird eine Meldung ausgegeben, die dem Entwickler folgende Möglichkeiten bietet:

Abort: Die Ausführung des Programms wird abgebrochen, der Debugger wird beendet.
Retry: Der Debugger wird ggf. gestartet und das Programm an der Stelle angehalten, wo die Assertion ausgelöst wurde. Damit kann man schön nachschauen, was denn da nun falsch gelaufen ist und warum.
Ignore: Das Programm soll trotzdem normal weitermachen, das kann unter Umständen böse enden, also Vorsicht in dem Fall.

Wenn du auf einen ASSERT aufläufst, der nicht von dir ist, dann musst du überlegen, was du falsch gemacht hast und / oder nachprüfen, ob du einen bekannten Fehler in der MFC gefunden hast. Im Team wende dich an den Kollegen, von dem der Code ist, der wird sich hoffentlich was dabei gedacht haben.

----------------------------------

Wofür man ASSERT benutzt: (Meine Meinung!!!)

- Wenn ein Wert auftritt, der nicht sein sollte, z.B. keine Daten gefunden, NULL-Zeiger, zu grosser Arrayindex.
- Wenn in einer switch ein Wert auftaucht, der da nicht sein dürfte.
- (Der ist jetzt wirklich nur ein kleiner Tipp) Als Todo-Markierung im Projekt, wenn du z.B. erstmal deinen Dialog angucken willst, und das Datenladen später machen willst. Dann kannst du statt des Ladens ein

ASSERT(FALSE);

schreiben und schon wirst du automatisch errinnert, dass du noch etwas vergessen hast.

----------------------------------

Wenn du eine ASSERT-Meldung bekommst ist also eine Situation eingetreten, die fehlerhaft ist. In dem Fall sollte dringend geprüft werden, was da falsch ist. Das Programm sieht oft so aus, als ob trotzdem alles okay ist - das böse Erwachen kommt dann oft an anderer Stelle.

In deinem Fall würde ich vermuten, dass es Probleme mit der Ressource gibt.

<Ironie on> Alle Klarheiten beseitigt? <Ironie off>

PS: Informier dich in dem Zusammenhang mal über VERIFY. Das kann ich leider nicht so gut erklären. Wenn ich noch über eine gute Beschreibung stolpere, werde ich die hier posten.

nun der erste fehler wird von dieser zeile verursacht:

HINSTANCE hinst = ::AfxGetResourceHandle();

meine hinst variable bleibt leer,
der nächste fehler wird wohl ein folgefehler darauf sein,
der wird beim erzeugen des dialogs ausgelöst, weil der
darauf kein handle hat oder so.

m_pDlg->Create(IDD_DIALOG1);

ich muss jetzt mal guxen warum das AfxGetResourceHandle nicht funktionier, eigentlich hab ich alles richtig gemacht.

How do I build an "extension DLL"?

When you're building a 32-bit extension DLL, define _AFXEXT on the compiler command line. If you look in AFXVER_.H, you'll see that this forces _AFXDLL to also be defined. So an "AFXEXT" DLL is an AFXDLL.

When _AFXDLL is defined, AfxGetResourceHandle returns a value stored in MFC's global data, which is shared by the .EXE, the extension DLL, and the MFC DLL. The handle returned identifies the module that will be searched first when looking for a resource.
(See the source code for AfxFindResourceHandle() if you're curious about the order of the search.)

Strictly speaking, what we need to load a resource is a module handle rather than an instance handle. (Instances share modules—that is, code and resources—but have different data.) A DLL has a module handle that is distinct from the handle of the .EXE.

You can use ::GetModuleHandle to get the handle for your DLL, then pass it to AfxSetResourceHandle so that your DLL is the first place searched for resources. But note that this removes the .EXE module from modules searched. You'll probably want to save a copy of the handle returned by AfxGetResourceHandle before calling AfxSetResourceHandle, then restore it once you're done loading the DLL resource.
Charlie Kester, Microsoft Developer Support, MSMFC, 7/19/95

Ausserdem klingt das Kapitel "Extension DLLs" interessant für dich. Schmöker da mal durch.

Ich vermute, du hast beim Erstellen der Dll etwas vergessen.