Über Fenster und Nachrichten hatte ich schon einmal gebloggt. Heute möchte ich ein praktisches Beispiel dazu einmal genauer unter die Lupe nehmen.
Auch wenn ich mich dabei auf Windows beziehe, wird der grundlegende Mechanismus wohl bei jedem Betriebssystem mit GUI ähnlich gehandhabt – zumindest, wenn es sich über eine Mouse bedienen lässt.
Wie funktioniert ein Klick?
Der Einfachheit halber gehen wir von einem Klick in ein bestimmtes Fenster aus, sagen wir, eine Schaltfläche.
Moderne Mäuse haben drei Tasten: links, rechts und mittel (meist als Wheelrädchen gebaut).
Für einen Klick brauchen wir nur die linke Taste.
Der Mousecursor bewegt sich über den Clientbereich der Schaltfläche. Beim Drücken der linken Mousetaste wird an das Fensterhandle der Schaltfläche eine WM_LBUTTONDOWN Message geschickt (es sei denn, Mouseevents sind gerade von einem anderen Fenster gecapturet – aber den Fall vergessen wir mal).
Aus dem wParam kann die Anwendung erkennen, ob noch andere Tasten gedrückt wurden. Der lParam enthält die Client-Koordinaten der Mousecursor-Position.
Die Anwendung kann hier bereits beginnen, das Mousedown-Ereignis abzuarbeiten, falls eine entsprechte Ereignisroutine zugewiesen ist. Oder sie wartet auf ein eine entsprechende WM_LBUTTONUP Message, die den Klick abschließt.
Wenn wir die Mousetaste gedrückt halten, währenddessen wir die Mouse außerhalb des Clientbereiches der Schaltfläche ziehen, und dann erst loslassen, bekommt die Schaltfläche das Mouseup-Ereignis nicht mit. Es wird kein Klick ausgelöst. So kann sich der Benutzer, der einen Klick angefangen hat, es sich noch währenddessen anders überlegen.
Drücken der linken Mousetaste und wieder Loslassen muss im Clientbereich des gleichen Fensters passieren, um als Klick darauf behandelt zu werden.
Dann gibt es aber auch noch Doubleclick-Messages, die ausgelöst werden, wenn zwei sehr kurz aufeinanderfolgende Klicks im Clientbereich eines Fensters ausgeführt werden. Der optimale Zeitabstand zwischen den Einzelklicks lässt sich bei den Mouse-Optionen konfigurieren.
Nach all dem Sermon ist es vielleicht auch für Anwender interessant, sich mal bewusst zu machen, was alles passiert, wenn man nur ein wenig auf den Mousetasten herumdrückt.
breakpoint 
Genital! Klingt doch nach ner super Sache.
LikeGefällt 1 Person
Ist natürlich ein ganz anderes Bedienkonzept als bei einem Tatschscreen.
LikeLike
Welche Events zur Verfügung stehen, hängt von der Programmiersprache ab.
In C#.NET hat man z.B. auch MouseDown, MouseMove, MouseUp und jeweils die Pre-Events dazu. Ausserdem kann man die Mouse capturen und die Ereignisse bubblen lassen oder auch nicht oder nur teilweise.
Click gibt’s eigentlich nur bei Buttons und davon abgeleiteten Klassen. Man kann den Click und den Doppelklick auch für andere Typen einfach implementieren.
So ein Klick ist aber absolut einfachstes Handwerkszeug. Viel schwieriger ist ein stimmiges, klares Bedienkonzept.
LikeLike
Die Beschreibung hier bezog sich auf generische Programmierung. Frameworks unterstützen dies natürlich und kapseln Ereignisse, womit sie dem Programmierer die Arbeit erleichtern.
LikeLike
Eben.
Ein Klick 😉 und der Klick ist implementiert.
LikeGefällt 1 Person
Es ist trotzdem interessant, zu wissen, wie das im Einzelnen abläuft.
LikeLike
Für andere bestimmt.
Ich selber programmiere jetzt schon sooo lange (mehr als 30 Jahre), dass das nicht mehr unter interessant läuft 😉
LikeLike
Als Naturwissenschaftlerin faszinieren mich gerade die Abläufe, die im Verborgenen stattfinden.
LikeLike
Als Ingenieur interessiert mich auch, wie etwas genau funktioniert und was dahintersteckt.
Trotzdem ist das ein alter Hut (für mich).
LikeLike
Zum Thema „Scrollrad“ muss ich sagen, es ist mir inzwischen sowas von in Fleisch und Blut übergegangen, dass der Scrollbefehl genau für das Fenster/den Bereich eines Fensters ausgeführt wird, über dem sich der Mauszeiger im Moment des Scrollens befindet, dass ich das Verhalten unter Windows wirklich unangenehm finde, wo das Fenster (bzw. der Bereich eines Fensters) welches/r zuletzt aktiv war, dann auch den Scrollbefehl abkriegt, obwohl der Mauscursor schon längst ganz wo anders ist. Eine echte Usability-Katastrophe, wie ich finde!
LikeLike
Das ist bestimmt nur Gewohnheit.
Ich erwarte, dass die Wheel-Messages an genau das Fenster gehen, das ich zuletzt aktiviert habe. Wenn dieses Verhalten einmal (warum auch immer, z.B. innerhalb einer merkwürdig implementierten Anwendung) abweichend ist, so irritiert und stört mich das.
LikeLike
Naja, es verlangt halt immer einen weiteren Klick, wenn man woanders scrollen will, als in dem aktiven Fenster (bzw. z.B. bei Explorer-Fenstern in der aktiven Hälfte). Das ist also definitiv eine geringere Usability, weil eine unnötige extra User-Interaktion nötig ist (nicht nur: Mauszeiger dahin bewegen, wo man scrollen will, sondern auch noch klicken, und damit womöglich auch noch ein Fenster in den Vordergrund holen, was dann wiederum andere, gewünschte Inhalte verdecken kann usw). Mag sein, dass man sich daran gewöhnen kann, aber das heißt nicht, dass es nicht die schlechtere Lösung wäre, rein unter objektiven Usability-Gesichtspunkten (wieviele Interaktionen sind nötig, um das gewünschte Ziel zu erreichen, hier: an eine bestimmte Stelle zu scrollen).
LikeLike
Nur weil ich das Rädchen bewege, heißt das nicht, dass ich dort scrollen will, wo der Mousecursor ist.
Ich habe häufig die Situation, dass innerhalb eines Anwendungsfensters verschachtelt mehrere scrollable Areas sind (auch übereinander mit unterscheidlicher z-order). Da wäre es völlig chaotisch, wenn nicht das aktivierte Fenster reagieren würde, sondern irgendein Parent oder Child.
Ich bestimme, welches Fenster reagiert, und nicht die zufällige Mouseposition.
LikeLike
Als Bediener eines PCs bin ich es doch, der die Mausposition bestimmt, d.h. ich schiebe den Mauszeiger dort hin, wo er eine Interaktion unternehmen soll: Klicken, Scrollen oder was es sonst noch gibt (Rechtsklick und Doppelklick fallen mir noch ein). Da ist nichts zufälliges dabei. „Zufällig“ ist der Mauszeiger nur dann positioniert, wenn ich ihn aus einem Textfeld, in dem ich schreibe, wegschiebe, damit er den geschriebenen Text nicht überdeckt. (Nebenbei: Deshalb mag ich auch Tastaturen mit Trackpoint so gerne, weil man da für den Wechsel zwischen Maus- und Tastaturbedienung nicht die Handposition ändern muss.)
Während ich jedoch die meiste Zeit nicht im Hinterkopf behalten will/muss, welcher Teil eines Fensters gerade aktiv ist, da mich das als user nicht zu interessieren haben sollte. Die Position des Mauszeigers ist das, was man als optisches Feedback hat, Stichwort „Mensch-Maschine-Schnittstelle“, während das aktivierte Element eines Fensters oft gar nicht optisch markiert oder hervorgehoben wird, oder nur so unmerklich, dass man gezielt danach schauen muss. Ich habe es jedoch nur selten erlebt, dass ich den Mauszeiger auf dem Bildschirm gesucht habe.
LikeLike
Schau dir mal diesen Screenshot an – da gibt es 5 Scrollbalken, die sich teilweise auf denselben Bildschirmbereich beziehen.
Das ist nur ein willkürliches, und wohl nicht das beste Beispiel.
Ich will wirklich wählen können, auf welches fenster sich meine Wheelmessage bezieht, zumal manche Anwendungen auch andere Aktionen (z.B. Zoomfaktor oder Fontgröße) damit verknüpfen.
Wo kämen wir hin, wenn Benutzereingaben irgendwohin geleitet würden, ohne dass vorher das zugehörige Fenster aktiv ist, bloß weil zufällig gerade der Mousecursor darüber schwebt?
LikeLike
Wie gesagt, „zufällig“ schwebt der Mauszeiger idR bei mir nirgends, sondern er ist immer da positioniert, wo er hin-intendiert wurde. Zu dem Screenshot muss ich sagen: Der äußere Scrollbalken is schon mal das, was man als erstes so positioniert, wie man es haben will. Das Fenster dahinter zähl nicht wirklich, weil dieses hervorlugen um 5 Pixel hinter dem gerade benutzten Fenster natürlich nicht geeignet ist, um darin zu scrollen (wozu auch, man sieht ja den Inhalt nicht). Das könnte also genauso gut minimiert sein, oder ganz dahinter versteckt oder ähnliches. Nun zu dem Browserfenster: Da ist es tatsächlich eine Unsitte mancher Webdesigner, Scrollbalken ineinander so zu verschachteln, dass praktisch keine „Freifläche“ mehr existiert, um die Seite gesamt herunterzuscrollen. Das ist ebenfalls schlechte Usability, weil man manchmal tatsächlich erst in einem der inneren Scrollbalken ganz nach unten scrollen muss, bis dann mal die gesamte Seite runterscrollt (noch schlimmer, wenn es solche Endlos-Inhalte sind, die am unteren Ende einfach nachgeladen werden, da denke ich mir immer „wer macht sowas nur?!?“). Ansonsten erwarte ich aber, dass von den inneren Scrollbalken immer der scrollt über dem das „MouseOver“ Event ausgelöst wurde, denn einmal zusätzlich wo hin klicken (und dann womöglich durch ungenaue Platzierung des Mauszeigers dabei auch noch was anklicken, was gar nicht angeklickt werden sollte) empfinde ich als unnötig, mühsam und schlechte Usability.
Das ist wohl so eins der Themen, wo wir maximal bei einem „agree to disagree“ ankommen 🙂
LikeLike
Wenn man eine Anwendung mit Tastaturshortcuts oder der Tabulatortaste bedient, so ist die Position des Mousecursors nicht aussagekräftig, aber Ereignisse sollen dennoch an ein definiertes Fenster gehen.
Ich stimme mit dir überein, dass wir uns hier wohl nicht einig werden.
Meine Specs werde ich trotzdem auch in Zukunft so formulieren, dass Mouseereignisse grundsätzlich an das aktive Fenster gehen.
LikeLike
Pingback: Computerfrustiges //1821 | breakpoint
Pingback: Es war einmal in #Twitterland //1976 | breakpoint