Re: Message Routing in Winform-Applikationen

Am Tue, 31 Jul 2007 19:43:42 +0200 schrieb Frank Dzaebel:

Hallo Frank,
vielen Dank für die Antwort. IMessageFiler + PreFilterMessage war mir
schon
bekannt - wo ist denn der Unterschied zum direkten Überladen von WndProc?
In beiden Fällen habe ich Zugriff auf das gesamte Dispatching.

Nein. Wenn Du z.B. die WndProc einer Form überschreibst, werden die
Nachrichten der Container und Controls in den Containern normal nicht über
diese WndProc verarbeitet. Bei der IMessage-Schnittstelle funktioniert das!

Ja natürlich .... hatte ich glatt übersehen (müsste ich natürlich wissen).


Vielleicht meinst Du auch etwas anderes. Vielleicht zunächst das
abschliessen, um dann über Deine weiteren Anmerkungen zu diskutieren. Da WPF
nun demnächst wichtiger wird, ja auch eine passende aktuelle Frage.

Jo, dann sag mal was dazu. Wie Elmar ja bereits empfohlen hatte, könnte man
die WPF-Mechanik in WinForms nachbilden - da hätte man eine sehr schöne,
allgemeine Lösung. Nur lohnt sich das IMHO nicht... später steigen wir ja
doch um, und dann ist der Aufwand umsonst.

Das Problem lässt sich allgemein so fassen: Der Zustand (enabled/disabled)
eines Commands hängt natürlich in erster Linie davon ab, wer den Focus hat
- schließlich beziehen sich Kommandos idR auf das fokusierte GUI-Element.
Leider gibt es ein paar Nebenwirkungen: auch andere Stellen der Software
(z.B. Background-Worker der übergeordneten Form) können Einfluss haben. Wir
brauchen also einen Mechanismus, der neben dem fokussiereten Element auch
die "offensichtlichen" weiteren Kandidaten berücksichtigt, was im
allgemeinen Falle nur ein Traversieren des Baumes bedeuten kann.

Zweite Aufgabe: Die Logik der Kommandos (Statusbestimmung, Ausführung) soll
an beliebiger Stelle stehen können. Zunächst (und im Normalfall) bei den
Controls selber, aber eben auch bei den anderen, "offensichtlichen"
Kandidaten (i.e. Form). In der WPF ganz hervorragend gelöst. Wie mach ichs
aber am Besten unter WinForms?

Grüße
Paule









.

Loading