OnMouseWheel wird an Hintergrund-App weitergeleitet

[DenkDirNix]

Hallo Welt,
ich habe eine alte Anwendung etwas aufgefrischt und jetzt folgendes

Verhalten:
Beim (schnelleren) Bewegen des Mausrades über dem MDI-Child-Fenster der Anwendung wird das Mausrad-Event an eine ggf darunter liegende andere Anwendung (z.B. Commander oder Delphi-Editor) weitergeleitet (unter Windows10).

NOTWENDIGE RANDBEDINGUNGEN (reduzierte Source anliegend):
- OnMouseWheel() für MDI-Child definiert
- Darin wird in eine Methode der MDI-Form gesprungen
- Deren Inhalt ist mit Lock- und UnlockDrawing() umgeben
- ... und läuft relativ lange, hier durch Sleep() simuliert

VERMUTUNG:
Da das Problem beim langsamen (eine Rasterstufe) Drehen am Rad nicht auftritt vermute ich mal, dass
- das erste OnMouseWheel-Event normal ankommt und verarbeitet wird
- das zweite (auf Windows-Ebene) kommt und auf die noch beschäftigte Bearbeitung trifft
- ... und das Windows deshalb die Anwendung als nicht existent ansieht und das Event an die darunterliegende sendet.

Ist nur eine gewagte Theorie, aber damit wäre es halt kein Delphi-Problem.
In Delphi12 ist am MDI ja geändert worden, kann jemand das da mal testen?

[DenkDirNix]

Hm, das Thema scheint wohl nicht so interessant zu sein.
Oder von mir zu schlecht beschrieben, nicht reproduzierbar?

[jaenicke]

Das ist ein Effekt, der zum Glück nicht direkt mit MDI zu tun hat, der unter Windows 10 auftritt. Zum Glück, weil es unter Windows 11 gefixt wurde. Das passiert mit Delphi 11 wie mit Delphi 12.

MDI ist hoffnungslos veraltet, wird von Microsoft nicht mehr gefixt und nicht mehr weiterentwickelt. Es hat sehr viele bekannte Bugs, die aber nicht mehr gefixt werden. Im Grunde ist das Setzen auf MDI heute so wie das Setzen auf die BDE für Datenbankzugriffe. Man kann nur hoffen, dass es einigermaßen läuft, muss aber jederzeit damit rechnen, dass die Anwendung mit dem nächsten Windows Update gar nicht mehr läuft. Für geschäftliche Zwecke kann man daher beides kaum mehr verwenden.

Nichtsdestotrotz gab es in Delphi selbst mit Delphi 12 einige Verbesserungen, aber das ändert nichts an den Bugs in Windows zu dem Thema, die außerhalb der Reichweite der Delphientwickler liegen.

Zitat von DenkDirNix:

Hm, das Thema scheint wohl nicht so interessant zu sein.

Wir reden von MDI...

[himitsu]

In den Mauseigenschaften gibt es eine Option "Inaktive Fenster beim Draufzeigen scrollen", heißt so z.B. in den Win10-Mauseinstellungen. (ich glaub hieß mal sowas wie "Das unter der Maus scrollen")

Das vielleicht mal umstellen?

Ansonsten bleibt dir wohl nur, es im Hauptfenster abzufangen und es an das für Delphi (nicht Windows) "aktive" Unterfenster weiterzuleiten.

[DenkDirNix]

Zitat von himitsu:

Ansonsten bleibt dir wohl nur, es im Hauptfenster abzufangen und es an das für Delphi (nicht Windows) "aktive" Unterfenster weiterzuleiten.

Das hast Du wohl mißverstanden:
Es kommt weder im MDI-Child noch im Hauptfenster an, sondern in einer fremden, zufällig darunterliegenden Anwendung!
Einfach mal reproduzieren (mit Win10, denn nach Jänickes Kommentar in Win11 wohl nicht mehr auftretend).

[himitsu]

Ich habe hier eine MDI-Anwendung und konnte sowas noch nicht feststellen.
XE und D10 bis D12 in Win10 und via RDP.

In Win11 noch nicht oft mit diesem Programm gearbeitet, aber es gab die letzten Jahre mehrere Versuche damit, und da war nichts diesbezüglich aufgefallen.

[jaenicke]

Ich kann es unter Windows 10 problemlos nachstellen. Hast du die Demoanwendung ausprobiert?

[himitsu]

Neee, dachte eine noch schlimmere MDI-Anwendung reicht aus.


Joar, LockDrawing ist Schuld.
Wird schnell gescrollt und es erwischt die kurze Lücke, dann rauschen einige Messages durch's Fenster.



PS: Bei mir ist "Inaktive Fenster beim Draufzeigen scrollen" im Windows aktiv.

Schalte ich das ab, dann wird immer nur im MDI-Child gescrollt.
Nichts geht durch und in der Hauptform wird auch nie gescrollt.

Mit der aktiven Option, wird auch im Hauptfenster gescrollt, wenn die Maus drüber liegt, und dort geht nichts durch, zu anderen Anwendungen.

[DenkDirNix]

Zitat von himitsu:

Neee, dachte eine noch schlimmere MDI-Anwendung reicht aus.

"Schlimm" ist halt relativ, es kommt schon auf die ganz oben genannten 4 Bedingungen an die für den Fehler alle erfüllt sein müssen.

Die Windows-Einstellung zu ändern kommt natürlich nicht in Frage, wie auch hier im Forum oft gesagt wird.
Ich werde wohl das LockDrawing() aus-IF-fen müssen wenn ich übers MouseWheel-Event hineinkomme.
Und das UnlockDrawing() dann am besten auch

[himitsu]

Zitat von DenkDirNix:

am besten

Unbedingt, sonst stimmt die Referenzzählung nicht mehr ... das zählt mit, wie oft diese Funktionen rekursiv verschachtelt ausgerufen wurden.