Re: Message Routing in Winform-Applikationen

Am Mon, 30 Jul 2007 20:52:19 +0200 schrieb Frank Dzaebel:

Hallo Paul,

gibt es in bei WinForms eine Möglichkeit, eigene Nachrichten "von oben
nach
unten" durchlaufen lassen zu können? Ich möchte nach Möglichkeit nicht
jeden Container mit Code zur Weiterleitung ausstatten. Ich denke mal, für
Cmd-Messages sollte es sowas ja bereits geben.
Ich brauche sowas, um den Aktivierungsstatus von globalen Kommandos (z.B.
cut/copy/paste) im Editmenü bestimmen zu können.

Für .NET 2.0 WinForms-Controls ist das *direkt* nicht vorgesehen. Es gibt
aber die Möglichkeit über IMessageFilter, wodurch Du alle Events aller
Controls - egal, ob in Containern - in einem PreFilterMessage-Handler
behandeln könntest:

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.

Wie ist denn das Verteilen von Messages im Framework? Ich möchte "oben" was
einfüllen (eine Msg mit Daten dran) und dann erreichen, dass diese durch
alle GUI-Elemente "fließt", d.h. von jedem GUI-Element "gesehen" wird. Aus
Performance-Gründen sollte dasjenige mit Focus zuerst drankommen, dann aber
auch die anderen. Wenn ein Control meint, dass die Msg von ihm zu
bearbneiten ist, soll das "Fließen" gestoppt werden können, da das Ergebnis
bereits feststeht.

Als Alternative habe ich mir überlegt, manuell folgenden Prozess zu
implementieren: Ich stelle das Control mit Focus fest, und frage dieses, ob
es die Anfrage beantworten möchte (dazu muss ich natürlich ein geeigentes
Interface machen). Wenn ja (Normalfall), stoppt der Prozess. Wenn nein,
gehe ich zum Parent, und mache dort das Gleiche (sofern dieser das
Interface implementiert). Danach frage ich alle Members des Containers (was
einen rekursiven Abstieg bedeuten kann), etc, etc. Im Prinzip ist es also
die Aufgabe, von einem Blatt eines Baumes aus den gesamten Baum zu
iterieren, bis irgendeiner "fertig" sagt.

Diese zweite Lösung wird sicher funktionieren, bedarf jedoch einiges an
manuellem Aufwand. Schön wäre es eben, wenn man eingebaute Mechanismen
verewnden könnte, wie z.B. das eingebaute Dispatching von Windows-Messages.
Ich bräuchte dann nur eine eigene Message zu definieren und das Framerwork
würde diese durch den Baum verteilen.

Das Ganze brauche ich, um z.B. den Zustand (enabled/disabled) von Menüitems
berechnen zu können (im OnIdle). Das hängt in erster Linie vom Control mit
dem Focus ab, aber nicht nur.

Grüße
Paule







.

Relevant Pages

  • A question regarding use of the Test Container to check ActiveX controls
    ... container my company has written that displays graphical information. ... When I try my control, which simply puts up a circle/ellipse at an X,Y ... it's just not working in the Test Container. ... //provide an inner border by moving in by 2 pels in all directions ...
    (microsoft.public.vc.mfc)
  • Re: Focus on control or container
    ... > I have written an ActiveX control container in ATL and a few ActiveX ...
    (microsoft.public.vc.atl)
  • Re: a ATL control with picture
    ... object asks container for a moniker through IBindHost, ... Displaying a picture is pretty straightforward, ... Word may not load a control until you scroll down to a page ... > Your dependent control is now instantiated, but it has no data to ...
    (microsoft.public.vc.atl)
  • Re: How to make my application resolution aware?
    ... the control and the corresponding sideof the container. ... Dock does one of five different things, ... Dock Left means that the control will always be pressed against the ... here's the trick to it: use Panels. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: a ATL control with picture
    ... This is exactly what in the OLE world is known as linking to ... ActiveX Control containers... ... > object asks container for a moniker through IBindHost, ... Displaying a picture is pretty straightforward, ...
    (microsoft.public.vc.atl)