Eingabeverarbeitung

[Zudomon]

Ich programmiere ja jetzt ohne VCL ( den vorgebenen Forms unter Delphi ) und mache das Fenster und die Eingabe über Windows API und dem normalen Message Handler.
Irgendwie kann ich in anderen Programmen keinen Doppelklick machen, also selbst wenn mein Programm nicht fokusiert ist. Ich habe auch das Problem auf andere Dialogboxen zu klicken. Z.B. wenn ich dann wieder zu Delphi switche, da das Programm abbrechen möchte und der mich Fragt, wirklich? Ja, Nein... Aber anklicken kann ich die Schaltflächen nicht, als ob er die Handles von anderen Programmen durcheinander haut. Das geht nur irgendwann, wenn wild im zwischen den Task switche.

Kennt jemand so ein Verhalten, was könnte ich da falsch machen??

Und ich habe noch eine Frage. Im Moment positioniere ich die Maus immer in die Mitte des Bildschirms. Das ist aber ungünstig, weil wenn mein 3D-Fenster nicht mehr unter der Mitte liegt, wird der Mauszeiger wieder sichtbar und wenn man nun klicken würde, würde die Anwendung den Fokus verlieren. Was kann ich da tun?

[gdsWizard]

Hallo Zudomon,


hört sich für mich so an das du die Maus noch gecaptured hast. Dadurch werden alle Mausklicks an das gecaptured Control gesendet, selbst wenn sie einem anderen Process gehören. Durch das Taskswitching mittels TaskManager wird die Mausfreigabe dann von windows erzwungen. Mit einem einfachem Trace im captured control für WM_MOUSEMOVE kannst du das nachvollziehen.


Gruss gdsWizard

[Zudomon]

Also ein SetCapture benutze ich nicht. ReleaseCapture hatte ich noch drin, wenn das Fenster den Focus verliert. Habe das auch mal auskommentiert. Aber ändern tut sich noch nichts... es muss irgendwas anderes sein. Es ist mir ein Rätsel, wieso Systemweit der Doppelklick ignoriert werden kann.

[Zudomon]

Hmmm... es scheint an folgender Funktion zu liegen, die ich mal irgendwo her hatte und die, wie ich dachte, mir einfach das Handle zurück gibt, welches gerade den Focus hat.

Code: Alles auswählen

function GetSysFocus: Integer;
var
  hFgWin, FgThreadID, hFocusWin: Integer;
begin
  hFgWin     := GetForegroundWindow;
  FgThreadID := GetWindowThreadProcessID(hFgWin, nil);
  if AttachThreadInput(GetCurrentThreadID, FgThreadID, True) then begin
    hFocusWin := GetFocus;
    Result    := GetFocus;
    AttachThreadInput(GetCurrentThreadID, FgThreadID, False);
  end else Result := GetFocus;
end;

[odenter]

Also eigentlich musst Du nur die entsprechenden WM_XXXX Messages in der Callback zu Deinem Fenster behandeln und es sollte alles normal funktionieren.
Hast Du vielleicht irgendwie mit Hooks was gemacht und nen globalen Hook installiert der Dir alle Events der Maus abfängt?

[Zudomon]

Ne, benutze keine Hooks... nur ganz brav meine WM_... Messages. Allerdings hatte ich mal irgendeinen Fall damals, wo ich gewährleisten musste, dass ich wirklich Systemweit den Fokus habe, kann mich aber nicht mehr erinnern, weswegen... das war noch für den Editor damals. Da hatte ich dann diese Funktion benutzt allerdings scheint die wohl irgendwas im System umzustellen.
Ähnliche Effekte hatte ich übrigens mal, als ich DirectInput benutzt hatte, danach konnte man auch dann kaum noch was aktivieren ohne da nicht ständig den Tast zu switchen.

[BeRsErKeR]

Und ich habe noch eine Frage. Im Moment positioniere ich die Maus immer in die Mitte des Bildschirms. Das ist aber ungünstig, weil wenn mein 3D-Fenster nicht mehr unter der Mitte liegt, wird der Mauszeiger wieder sichtbar und wenn man nun klicken würde, würde die Anwendung den Fokus verlieren. Was kann ich da tun?

Darf ich mal fragen, was du eigentlich vor hast bzw. bezwecken willst? Warum positioniert man denn die Maus manuell? Wenn das etwas mit Rundumblick in einem 3D-Fenster zu tun hat, kann man das auch besser lösen bzw. wenn dann schon die Maus in der Mitte des 3D-Fensters platzieren und nicht in der Mitte des Bildschirms.

Und vom Verarbeiten von Messages kannst du nicht wirklich andere Prozesse beeinflussen, es sei denn du rufst irgendwelche WINAPI Funktionen auf. Diese Funktion, die du für die Ursache hälst, sieht mir auch sehr verdächtig aus, zumal sie ja da ganz offensichtlich auch den Input für andere Fenster/Prozesse beeinflusst bzw. beeinflussen kann.

[Zudomon]

Wenn das etwas mit Rundumblick in einem 3D-Fenster zu tun hat, kann man das auch besser lösen

Wie wäre es denn besser?

bzw. wenn dann schon die Maus in der Mitte des 3D-Fensters platzieren

Und was ist, wenn der Benutzer das 3D-Fenster so weit rüber schiebt, dass das Zentrum des Fensters außerhalb des Monitors liegt?

[odenter]

Dann positionierst Du den Cursor in der Mitte des Fensters, und der Anwender hat selbst schuld. :) Oder in dem Fall, schiebst Du das Fenster zurück in die Mitte des Desktopfensters.
GetClientRect oder so ähnlich müsste die WinAPI Funktion heissen.

Den Task zu switchen um ein anderes Fenster zu aktivieren wäre ja erstmal normal, es sei denn es ist ein MDI-Fenster oder ne Dialogbox, wobei die Dialogbox ja modal angezeigt wird.
Es ist auch normal das, wenn man ein anderes Fenster anklickt dieses den Focus bekommt. Ich würde daran nichts ändern oder versuchen es zu ändern. Ist halt normales Verhalten.

[BeRsErKeR]

Wenn das etwas mit Rundumblick in einem 3D-Fenster zu tun hat, kann man das auch besser lösen

Wie wäre es denn besser?

Zum Beispiel die unten genannte Variante.

bzw. wenn dann schon die Maus in der Mitte des 3D-Fensters platzieren

Und was ist, wenn der Benutzer das 3D-Fenster so weit rüber schiebt, dass das Zentrum des Fensters außerhalb des Monitors liegt?

Entweder du verhinderst das indem du das Fenster verschiebst oder ein Verschieben bis dahin gar nicht zulässt. Ansonsten könntest du mit etwas mehr Rechenaufwand die Maus halt so nah wie möglich am Mittelpunkt des Fensters positionieren (halt am Bildschirmrand) und das Offset bei Mausbewegungen einkalkulieren. Sollte möglich sein.