[Plugin] Fensterschleifenproblem

Hossa!
Erstmal wichtig im Vorraus: Ich programmeire nonVCL!
Ich hab folgendes Problem:
Ich wollte einen Texteditor speziell fuer Programmierer bauen, bei dem es eben auch moeglich ist Plugins zu installieren (dies sind dann DLL's). Jedes Plugin kann sich etweder ein eigens Fenster, eine Tolbar oder gar nichts zuweisen lassen. DIe DLL soll dann die Nachrichtenschleife fuer das zugewiesene FEnster uebernehmen. Nun ist folgendes Problem:
Fuerde ich in meiner Nachrichtenscleife einfach vor jeder verarbeitung abfragen, ob die Nachricht an eines der Pluginfester gehen wuerde, muesste ich unglaublich viel Rechenarbeitleisten, um sie umzuleiten. Und sobald die Nachricht an ein Childfenster vom Pluginfenster geht, erkennt man das ja nicht sofort, wenn man nicht getParent() aufruft.
Kann man nicht alle Nachrichten autamtisch weiterleiten (Fensterklasse?).
Oder wie wuerdet ihr das Realisieren? (Tutorial zum THema Plugins?).

Gruss Crock

In der Fensterklasse eines Fensters wird festgelegt, welche WndProc-Funktion zur Nachrichtenbehandlung aufgerufen wird. Diese Fensterklasse hat nichts mit OOP zu tun. Eine Fensterklasse ist eine Struktur vom Typ WNDCLASS. Deren Member lpfnWndProc will einen Zeiger auf die aufzurufende WndProc-Routine. So kann man jedem Fenster eine eigene Nachrichtenbehandlung zuweisen. Du schreibst, du verwendest nicht die VCL, aber du schreibst nicht, was du denn stattdessen verwendest. Davon hängt aber ab, wie du dein Problem lösen kannst.

Gawayn

Achso, ich dachte das waere klar. Also ich benutze jetzt das WInAPI, ich dachte an Fensterklassen, weil dort ja die FensterProceduren ja festgelegt werden und das ich dann fuer jedes Pluginfenster einfach eine neue Klasse erstelle.Dass das nichts mit OOP zutun hat, weiss ich. Ich hatte das mal Versucht via,... ich weiss gerade nicht wie dass heisst, "setWindowLong()" oder so, das hat aber nicht funktioniert. Also, ich bitte um Ideen.

Wie ich in meinem vorherigen Post schrieb, würde ich als erstes versuchen, anhand der Fensterklassen für jedes Fenster eine eigene WndProc zu definieren -- allerdings habe ich mit der Programmierung eines Plugin-Containers keine Erfahrung und kann daher nicht sagen, welche Probleme auftreten könnten. Was ich nicht ganz verstehe, ist, weshalb das Verteilen der Nachrichten so viel Rechenzeit in Anspruch nehmen soll. So wie ich das sehe, dürfte eigentlich überhaupt kein Mehraufwand auftreten, da es ja schließlich egal ist, WER die Nachricht erhält -- interessant ist nur, DASS überhaupt eine Nachricht im Queue existiert.

Übrigens, Crock: Ich hab auf deiner Website den Artikel zu Vigenère gelesen. Deine Behauptung, sie sei für Profis schwer zu knacken, ist ETWAS übertrieben. Der Angriff ist nicht gerade schwierig. Als ich noch in der 11. Klasse war, habe ich einmal ein Programm geschrieben, das zu beliebigen Vigenère-verschlüsselten Texten das Passwort berechnet. Vigenère taugt noch nicht einmal für Amateure.

Gawayn

<ot> Das ist von der Schluessel-laenge und -komplexitaet (assoziationsmoeglichkeit) abhaengig. Natuerlich kann der Schluessel sogar 1/3 so lang sein wie der Text. SObald die ersten z.b 8 Buchstaben hat und man erkennt einen Bekannten text (z.B "Sein oder"...), kann man den Schluessel schnell vervollstaendigen.
Und Vigenere mit einem Schluessel solang wie der Text, nennt man ja One-Time-Pad, der als "unknackbar" (ausgenommen Bruteforce, damit ist alles knackbar) gilt.
</ot>

Mit der Fensterklasse:
WIe meinst du das mit Definieren einer eigenen WndProc. Soll ich fuer jedes Fenster eine eigene Fensterklasse anlegen (was bei einer neuen Toolbarklasse nicht so einfach wird), oder soll ich im nachhinein die Funktionsadresse aendern (wenn ja, weisst du wie das geht?)? Oder reden wir die ganze Zeit aneinander vorbei (hab ich ja das Gefuehl )

Grundsätzlich würde ich sagen, dass du beim Anlegen des Fensters für jedes Fenster eine andere WndProc angibst. Wenn du mit der WinAPI programmierst, kreierst du ja jedes Fenster selber und kannst somit die WndProc selbst festlegen. Aber auch, wenn alle Nachrichten an das Hauptfenster gehen -- wieso wäre das zu langsam? Leider kann ich dir keine tiefergehenden Infos geben.

SObald die ersten z.b 8 Buchstaben hat und man erkennt einen Bekannten text (z.B "Sein oder"...), kann man den Schluessel schnell vervollstaendigen.

Zum Vergrößern anklicken....

Nun ja -- wenn Textlänge und Schlüssellänge in einem einigermaßen vertretbaren Verhältnis zueinander stehen, benötige ich weder Schlüssel- noch Klartextteile. Dann berechne ich den Schlüssel einfach so, ohne jede Info über im Klartext enthaltende Wörter.

Gawayn

<ot>Man weiss es nicht </ot>
Um ehrlich zu sein, hab ich das bis jetzt nie so gemacht, fuer jedes Fenster (auch Toolbars, Button, etc sind ja Fenster) anzulegen. Fuer die Fenster (die wohl meistbekantnen Hauptcontainer fuer Buttons etc hab ich das schon gemacht. Ich werd mal schaun ,was ich mache.

Wegem dem lange dauern: Al Empfaenger ist ja nur ein HWND angegeben. NIcht Ursprungsfenster o.ae. Deswegen muesste ich beim ermitteln des Parents auf beliebig tiefe verschatelungen gefasst sein, und dann schauen, ob irgendwann ein Plugionfenster als Eregnis auftaucht. Und das geht bestimmt einfacher (und wenn es Fensterklassen sind). Ich werds aber mal so versuchen.

Danke fuer die Diskussion (ich find sowas immer interessant).
MfG
Crock

Hm -- um mir dazu Gedanken machen zu können, müsste ich mehr über die Struktur des Ganzen wissen. So richtig kann ich mir nämlich noch keinen Reim machen, wie dein Programm eigentlich mit den Plugin-Fenstern umgeht.

Gawayn

Es funktioniert Ansatzweise schonmal so wie ich es will, doch sieht mein Code jetzt richtig Schlimm aus, und ich werd ihn jetzt nochmal ordentlich schreiben (Pluginunit etc).

Was mein Programm macht:
Es soll ein Allround-Editor speziell fuer Programmierer werden, der alleine eigentlich nicht mehr kann als Neu, Oeffen, Speichern, Drucken. Mit nem schicken EIngabefeld in der Mitte, einer einzigen Toolbar oben und einer Statusleiste fuer Zeilenanzeige. Und Plugins laden kann es eben auch, die durch DLL's repraesentiert werden. Und darauf basiert das ganze. Ich werde einige Plugins schon fertig mitgeben (Compilieren, Farben, Standardgereuste einfuegen). Jedes Plugin kann sich entweder Kein Fenster, eine Toolbarleiste oder ein eigenes Fenster anlegen lassen, in welchem da eben Button o.ae. zum Ausfuehren der "Faehigkeit(en)" der Plugins sind.
Und da komtmdas neue Problem:
Im moment lege ich fuer jedes neue Plugin eine neue Fensterklasse an (relativ).
Nun gibt es aber schon eine Toolbarklasse. Kann man das irgendwie ableiten (mri ist klar, das hat nichts mit OOP zutun)? Denn wie krieg ich sonst die Nachrichten der Pluginleiste an die in der DLL integrierten WndProc weitergeben?

So, ich hoffe es ist alles klar, sonst wieder posten.

Also, ich schreib jetzt mal, wie ich das ganze Prob angehen würde:

1. Das Hauptprogramm startet.
2. Das Programm lädt eine Plugin-DLL.
3. Das Programm ruft eine Infofunktion in der DLL auf, um zu erfahren, ob die DLL ein Fenster will, eine Toolbar oder gar nichts. Die Infofunktion teilt dem Programm auch mit, wieviele und welche Controls es an welchen Stellen haben will und mit welchen Funktionen sie verknüpft sein sollen.
4. Das Programm erstellt die Fenster, Toolbars und Controls so, wie die DLL es will. All diese Controls speichert es in einer Liste zusammen mit der zugehörigen DLL und der jeweiligen Funktion in dieser DLL.
5. Das Programm tritt in die Nachrichtenschleife ein.
6. Das Programm empfängt einen Klick auf einen Button.
7. Das Programm prüft, ob dieser Button in seiner Plugin-Control-Liste ist. Wenn ja, ruft es die Funktion in der DLL auf, die für diesen Button definiert wurde.

Hört sich das für dich praktikabel an?

Gawayn