Alle Systemweiten Eingaben abfragen

[jaenicke]

Wobei dir hoffentlich klar ist, dass du so nicht unbedingt alle Tastendrücke erwischst und auch nicht unbedingt in der richtigen Reihenfolge.
Aber wenn das für deinen Anwendungszweck kein Problem ist, gibt es da ja kein Problem.

Hintergrund:
Wenn in dem Zeitraum zwischen zweien deiner Abfragen zwei Tasten gedrückt wurden (und ein Timer ist was das angeht ja nicht immer zuverlässig, z.B. falls der PC gerade zu tun hat), bekommst du es nicht mit (wenn es dieselbe Taste war) oder die Tasten in der Reihenfolge der Tastencodes statt gedrückter Reihenfolge (wenn es unterschiedliche waren).

[Destroyer446]

Ich will nur eigene Aufzeichnungen von immer wiederkehrenden Abläufen machen,
und falls sie falsch sind, kann ich sie ja nochmal machen.
Ich würde aber gerne noch das Fensterhandle von dem Fenster bekommen, das gerade aktiv / im Vordergrund ist.

Wie kriege ich das hin?

Danke

[DeddyH]

Wenn man das wörtlich übersetzt, kommt man z.B. auf GetForegroundWindow

[Destroyer446]

Da hätt ich suchen können

Aber Danke

Jetzt habe ich erstmal nichts mehr für euch ^^

[DeddyH]

In dem Zusammenhang gerade gefunden, aber selbst noch nie benutzt: GetGUIThreadInfo. Das könnte auch noch interessant sein, zumindest liefert es ausführlichere Infos.

[Destroyer446]

Kann man irgendwie ein eigenes OnIdle Ereignis erstellen?
Ich kann mir zwar per App: TApplication; eine neue Application erstellen,
aber wenn ich der ein OnIdle Ereignis zuweise, passiert nichts^^

Ich bräuchte aber für die Unit "GlobalPressedKey" ein eigenes OnIdle Ereignis,
damit ich den Timer weglegen kann..

€dit: Ich verwende jetzt doch einfach TTimer...
Geht einfacher

Danke!

Mfg

[DeddyH]

Es gibt eine globale Variable namens Application, deren OnIdle kannst Du einen Eventhandler zuweisen.

[jaenicke]

Wobei man besser TApplicationEvents nehmen sollte, da man mit OnIdle alle anderen Handler klaut (und ggf. selbst überschrieben wird). TApplicationEvents hingegen arbeitet auf multicast Basis, es funktionieren also auch mehrere dieser Objekte.

Ob TTimer oder OnIdle macht aber ohnehin in diesem Fall keinen großen Unterschied, nur dass OnIdle eher noch unregelmäßiger aufgerufen wird, es sei denn man lässt Done auf False (aber dann wird es ständig aufgerufen --> auch nicht gut). Deshalb macht ein Timer mehr Sinn.

Und wenn es nicht so wichtig ist, dass wirklich alles angefangen wird, ist das auch besser als ein Hook da der den Rest des Systems negativ beeinflusst, wenn auch bei korrekter Implementierung kaum spürbar.

[himitsu]

Der Witz an TApplicationEvents, das hängt sich selber an diese Events, wie z.B. OnIdle.
Es hängt sich aber nur einmal daran und ruft darüber von allen existierenden TApplicationEvent-Instanzen die Methoden auf.
(hätte mir gewünscht, daß Emba dieses intern verbunden hätte )

Das hat einen netten Nachteil, denn es gibt grauenhaft programmierte Komponenten (EurekaLog z.B.), welche sich auch an diese Events hängen, nicht TApplicationEvents nutzen und somit andere daran hindern sich ordentlich dort zu registrieren, also über TApplicationEvents.

Aber dennoch rate ich unbedingt zu TApplicationEvents, auch wenn man manchmal noch manuell etweas eingreufen muß, um die von Anderen verbogenen Events wieder gradezurücken.

[hathor]

Ich habe was Interessantes gefunden:

Zitat:
Code for the watching.dll needed for the component TWatch.
Note that system-wide watching is *not* possible without
a dll.

This is NOT Freeware: It's PostCardWare. When you use
this component or think it's useful, send me a post-card
to: Florian Bömers, Colmarer Str.11, D - 28211 Bremen, Germany

And of course, I am very interested in any application
that uses this dll (or any other application you wrote).
If so, mail me (not the program, just an URL or similar) !

(c) 1997/1998 by Florian Bömers
(using memory files: seen in c't 07/1997)

send any comments, proposals, enhancements etc. to:
[e-mail]
---
Im ZIP-File ist alles vorhanden.