Re: Message Routing in Winform-Applikationen

Hallo Paul,

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).

Schön, dann können wir mal zum Event Routing übergehen.



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.

Tja, das sehe ich ähnlich. Man möchte und sollte das Rad nicht doppelt erfinden. Zwar lässt sich WPF innerhalb von WinForms und WinForms innerhalb von WPF ausführen, aber man muss da ganz vorsichtig mit den Erwartungen sein und gründlich in den Details vorchecken, bevor man Hybrid-Lösungen angeht. Das würde ich nicht machen, wenn es um einheitliches globales Event-Routing geht.

Ich denke, eine Nachbildung wäre zwar das sauberste, aber pragmatisch solltest Du eine Zwischenlösung benutzen. Dazu gleich.



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.

Aha, also wenn z.B. der Focus wechselt, dann soll ein Control auch einen anderen Zustand bekommen.
Ich würde aus Einfachheit zu einem globalen Handler tendieren. Also eigentlich dem IMessageFilter.
Ich muss aber sagen, dass ich evtl. von Deinem App-Kontext noch zu wenig weiss, um eine seriöse gute Antwort geben zu können. Nichts desto trotz, i'll try.



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.

Naja, Du brauchst evtl. keinen Baum, wenn Du den Control-Container-Baum meinst. Ich sehe momentan keine Probleme beim BackgroundWorker. Bei Modifikationen aus anderen Threads nutzt Du ja sicher Control.Invoke und hast so keine Einschränkungen.



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?

Seh ich eigentlich auch keine Probleme. Ggf. mit einem eigenen ExtenderProvider.
Wenn es alles Deine eigenen Control-Klassen sind, eher über normale Eigenschaften.


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

.

Relevant Pages

  • Re: Is there any hope for Microsoft ?
    ... But WPF isnt really about controls, ... Tell me again how it's gonna deliver a very WinForms like option with the current library of only "basic" controls, maybe with WPF version 2 they will flesh out the controls library. ... In the mean time I just don't think most developers will share your exuberant enthusiasm to completely abandon WinForms and switch to WPF but they will stick with WinForms when WinForms will do the job and they will enhance and extend their WinForms apps with WPF where graphical elements are desirable. ...
    (borland.public.delphi.non-technical)
  • Re: WPF apps using .NET 2.0 assemblies? Can it be done?
    ... I am building a specific WPF application which uses WPF ... Windows. ... It lets you put the WinForms ... controls inside WPF, which I think is what you're asking for. ...
    (microsoft.public.dotnet.framework)
  • Re: Rekompilieren von VB6 und .NET
    ... Langfristig mehr Chancen, ..., sehe ich in Konzepten wie der WPF, ... Punkt 10. ... Hebt im wesentlichen darauf ab, daß nun die Controls in einem Fenster keine eigenen Fenster mehr haben, sondern sich die Zeichenfläche des Hosts teilen. ... "WPF takes the radical step of disassociating the appearance from the control. ...
    (microsoft.public.de.vb)
  • Re: WPF vs WinForms
    ... Data binding isn't what it is in WinForms, and there's nothing equal to the DataGridView, which while it can be a pain in the a**, is very flexible. ... Right now I think that is where the strengths are in WPF. ... Give us a Menu that you don't have to edit in Xaml. ... but I thought the design was very well done. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: WPF--a threat to WinForms?
    ... In my opinon Enterprise desktop applications already ... see WPF having a lot to offer over WinForms to most enterprise desktop ... Windows Presentation Foundation (WPF) ...
    (microsoft.public.dotnet.languages.csharp)