Formular in DLL definieren und über LoadLibrary verwenden

joerider

Hallo Leute,

hat von Euch schon jemand probiert, ein Fomular in eine DLL zu packen und dieses dann über LoadLibrary und GetProcAddr zu verwenden?

Habe das kurz probiert, das Formular wird angezeigt, aber es kommen seltsame Probleme...

- einerseits bleibt das Programm in einer (internen) Endlosschleife hängen
- andererseits funktioniert die Tab-Taste nicht und
- weiters bin ich mir nicht sicher, ob und was ich einen setOwner und/oder setParent-Aufruf machen soll/muss.

Zur weiteren Erklärung: Ich versuche ein Plug-In-System zu implementieren, wo ich eine Voransicht aus der DLL in der EXE anzeigen will und wenn ich dort etwas mache, soll das zugehörige Formular aus der DLL aufgerufen werden.

Wäre Euch für Hinweise dankbar.

DLL: beim Aufruf von "show" soll das Formular IDD_MAINFRAME angezeigt werden.
Hier geht die Tab-Taste gar nicht.

void JMainFrame::show()
{
	if (!window_visible_)
	{
		Create(IDD_MAINFRAME,this);
		ShowWindow(SW_SHOW);
		window_visible_=true;
	}
}

void JMainFrame::hide()
{
	if (window_visible_)
		DestroyWindow();

	window_visible_=false;
}

Hier die Spielerei mit dem Preview-Fenster, das das andere Fenster anzeigen soll (hier kommt die Endlosschleife, wenn man ein CEdit plaziert und dann die Tab-Taste mehrmals drückt)

void CRmsvVideoApp::createCtrl(long *parent_wnd)
{
	CWnd* pWnd = (CWnd*) parent_wnd;

	if (parent_wnd) 
	{
		preview_=new JPreview();
		preview_->Create( IDD_PREVIEW, pWnd );
		//preview_->Create(NULL,"title",WS_VISIBLE,rect,pWnd,IDD_PREVIEW,NULL);
		//preview_->SetWindowPos( pWnd, 200,20,100,100, SWP_SHOWWINDOW |SWP_DRAWFRAME|SWP_NOSIZE );

		//preview_->ShowWindow(SW_SHOW);
	}
}

void CRmsvVideoApp::deleteCtrl()
{
	if (preview_ != NULL)
	{
		preview_->DestroyWindow();
		delete preview_;
	}
}

Martin Richter

1. Du hast keine Nachrictenschleife.
2. D.h. weiterhin Du hast Nachrichten Bearbeitung in der Messageloop. Für die Tab-Behandlung ist das aber notwendig (IsDialogMessage)
3. Solltest Du schon ein Parent Window beim Erzeugen angeben. Nicht erst mit SetParent setzen. Bzw. SetOwner gibt es nur in der MFC.

Frage: Schreibst Du auch das Hauptprogram, dass die Plugins nutzen soll, oder hast Du auf das keinen Einfluß?

Tipp: Beschäftige Dich dringend mit Extension DLLs wenn die Parent Applikation auch MFC benutzt.

joerider

Hallo und danke für die rasche Antwort!

zu 1 und 2: ok, muss da muss ich mich wohl noch intensiver damit beschäftigen

zu 3: ist, soweit ich weiß, jetzt nicht unbedingt notwendig. Das Ganze entstammt daher, dass das Preview-Fenster gleich geladen wird, aber nicht gesagt ist, ob das "große" Fenster überhaupt benötigt wird. D.h. ich wollte es erst erzeugen, wenn ich weiß, dass ich es brauche.

Ja, das Hauptprogramm liegt auch ganz in meiner Hand.

Der Sinn hinter dieser ganzen Sache ist, dass die Anwendung auch auf einem Read-Only-Memory laufen können soll. Ich vermute mal, dass Extension-DLLs Einträge in der Registrierung benötigen, was jedoch keinesfalls so sein soll. Das Hauptaugenmerk soll darauf liegen, dass man eine bestehende Anwendung durch Hinzufügen um eine DLL in ein bestimmtes Verzeichnis um Funktionen erweitert werden können soll.

Martin Richter

Extension DLLs benötigen keine Registry Einträge. Wie kommst Du darauf. Das hat nichts mit COM zu tun...

joerider

Martin Richter schrieb:

Extension DLLs benötigen keine Registry Einträge. Wie kommst Du darauf. Das hat nichts mit COM zu tun...

Aber man braucht dazu eine Installation für die MFC, oder?
Also statisch linken geht wohl nicht und somit kann man das Programm dann nicht von einem Read-Only-Datenträger laufen lassen, ohne irgendetwas zu installieren?!

Dann wäre das ganze Verfahren mit den Erweiterungs-DLLs nämlich für mich komplett wertlos.

Jochen Kalmbach

Du kannst die CRT/MFC DLLs auch auf diesen Datenträger mitliefern und dann AppLocal starten... einfach die DLLs und die dazugehörigen Manifeste in das gleiche Verzeichnis legen.

Du sollrtest vielleicht noch beachten, dass es gut wäre, wenn Du Deiner EXE/DLLs das Flag mitgeben würdest, dass sie von einem "entfernbaren Datenträger" gestartet werden!!! (/SWAPRUN:CD)

joerider

Jochen Kalmbach schrieb:

Du kannst die CRT/MFC DLLs auch auf diesen Datenträger mitliefern und dann AppLocal starten... einfach die DLLs und die dazugehörigen Manifeste in das gleiche Verzeichnis legen.

Du sollrtest vielleicht noch beachten, dass es gut wäre, wenn Du Deiner EXE/DLLs das Flag mitgeben würdest, dass sie von einem "entfernbaren Datenträger" gestartet werden!!! (/SWAPRUN:CD)

Gilt das auch in VC6? Gabs dort auch schon Manifeste? Ein kurzer Blick in die MFC hat gezeigt, dass erst ab VC2005 Manifeste generiert werden können.

Wenn ich mich nicht irre, ist ja VC6 die letzte Version, die ohne Schnickschack ala .net-Framework, das ja installiert werden muss, auskommt um wirklich eigenständige (statische) Anwendungen zu schreiben.

Oder irre ich mich doch?

Martin Richter

joerider schrieb:

Oder irre ich mich doch?

Ja! Du bist sowas von auf dem Holzweg, dass man es kaum für möglich hält (ich zumindest). Ich weiß nicht wieviel 10te mal das diskutiert worden ist.

Mit jeder VS Version (nach VC6) kann man Softwareherstellen die ohne das .NET Framework auskommt, und Programme erzeugen, die ganz für sich alleine lauffähig sind.

Woher hast Du denn Dein Wissen?
Sicherlich von keiner einigermaßen seriösen Quelle...

VC6 ist alt und Schrott gegen dass was die neuen VS Versionen bieten!

joerider

Mir hat man gesagt, dass Microsoft den Intermediate-Code mit .Net eingeführt hat und somit jedes Programm, das mit einer .Net-Version geschrieben wurde, sei es C++, C#, VB denselben IC generiert.

Gilt das also nicht für alle Projekte? Welche Projektart ist das dann, die diese Komponenten nicht einbindet? Woran erkennt man das?

Welchen Projekttyp kann ich also verwenden, wenn ich, wie ich schon geschrieben habe:
- eine EXE für einen Wechseldatenträger (ohne Installation) mit
- DLLs für Erweiterungen mit Formularen (auch ohne Installation)
erstellen möchte? Welche Kompilierungsparameter darf ich dann nicht verwenden?
Kann man diese Manifeste, die Jochen Kalmbach angesprochen hat, auch mit den Express-Versionen erstellen?

Was ist der tiefere Grund, warum man Erweiterungs-DLLs nicht statisch linken darf/kann?