Explizites tasten event auslösen

[gibb]

Danke jedenfalls für deine Hilfe

Irgendwie sollte es doch noch mehr Profis in delphi Praxis geben. Es kann doch iwie nicht sein das dieses Problem bisher noch unbekannt ist. Und es muss doch möglich sein ein Tastenevent an eine Applikation zu senden OHNE das ctrl/Shift oder andere modifikationskeys berücksichtigt werden.

Gruss gibb der sich über jede weitere Antwort unglaublich freuen würde da mich genau das Problem davon abhält meine Applikation weiter zu entwickeln.

[gibb]

hi, noch ne idee, liesse sich was über das Zahlenfeld auf der tastatur machen? Das sind doch bereits extendet keys. Ich hatte das so gelöst um shift zu umgehen. bei ctrl hats leider nicht ganz geklappt ^^'

Gruss gibb der hofft dir damit einen denkanstoss geliefert zu haben

[idefix2]

Ich fürchte, auch nicht, eben wegen control und wohl auch wegen numlock.

Das einzige, was mir einfällt, was funktionieren müsste, ist recht aufwändig: nämlich eine globalen MessageHook Routine schreiben, damit kannst Du alle tastaturbezogenen Messages überprüfen und gegebenfalls modifizieren. Ich bin zur Zeit an so etwas dran, aber da einzusteigen ist ein absoluter Horror - Siehe mein eben gemachtes Posting in einen andreen Thread

[gibb]

witzig war, das numlock das ganze nicht beinflusst hat, wie das möglich war, war mir selber ein rätsel.

[gibb]

Die frage ist immernoch offen. Hat niemand sonst noch ne idee?

Ich könnte sonst auch auf anfrage den Source rausgeben wenn jemand das ganze testen möchte.

gruss gibb

[idefix2]

Wenn Du den Code postest, schau ich es mir an - leider bin ich im Moment ziemlich unter Druck, ich kann also nicht versprechen, es gleich heute zu machen,aber innerhalb einer Woche finde ich sicher Zeit, hineinzuschauen. Vielleicht fällt mir etwas ein.

[gibb]

Ich schick dir das Projekt per mail.

[idefix2]

Hallo, ich habe mich jetzt etwas intensiver mit Deinem Problem beschäftigt, und habe - glaube ich - die Ursache ziemlich zuverlässig identifiziert. Es ist so, wie ich schon in einem früheren Posting vermutet hatte: Die "echten" Tastaturereignisse (wenn Du eine Taste gedrückt hältst, werden mit sehr hoher Frequenz immer wieder Keydown Ereignisse erzeugt) fädeln sich zwischen die von Dir künstlich erzeugten Tastenereignisse ein und neutralisieren dadurch Deine Keyups, noch bevor die Ziffern, die Du schickst, eintreffen.

Ich habe probeweise die Funktion SendInput an Stelle von Postmessage versucht, um eine Folge von Tastenereignissen zu schicken, zwischen die sich nichts zwängen kann, damit funktioniert es einwandfrei. Leider lässt sich damit Dein Problem nicht lösen, weil sendInput kein Fensterhandle als Parameter kennt und nur an das Fenster mit aktivem Focus schicken kann.

Ich fürchte, dass deshalb die einzige - sehr aufwändige - Möglichkeit für Dich wäre, einen globalen Keyboardhook zu implementieren, der alle Tastaturereignisse abfängt, und sie nur weiterreicht, wenn Du gerade nicht beim Befüllen Deines Editfelds bist. Wenn Du gerade Dein Editfeld befüllst, muss der Hook die echten Tastaturereignisse abfangen und zwischenspeichern, und darf sie erst dann erneut in die Messagequeue stellen, wenn Dein Programm mit dem Befüllen des Editfelds fertig bist. Ich habe mich letztens mit der Programmierung eines sehr einfachen keyboard Hooks beschäftgit, der sich um die ShiftLock Taste kümmert. Das Programm funktioniert im grossen und Ganzen halbwegs, und wenn Du Dich drübertrauen willst, kann ich es Dir als Vorlage zukommen lassen (Alle Tutrials und Beispielprogramme, die Du zum Thema Keyboardhook findest, reagieren nur auf Tastaturereignisse, ohne sie zu beeinflussen, aber dabei entstehen erst die Schwierigkeiten).

Ein anderer Lösungsansatz fällt mir gerade ein: Nur sehr wenige Leute halten die Shift-Tasten ständig gedrückt. Wenn du einfach darauf wartest, dass der Tastenstatus oben ist, bevor Du Deine Komponente anfüllst, umgehst Du das Problem auf einfache Weise.
Wenn während des Anfüllen des Feldes die Umschalttasten gedrückt werden, einfach Feldinhalt löschen und wieder von vorne anfangen, wenn der Umschaltstatus passt. Die Lüftersteuerung ist ja nicht so etwas dringendes, wenn das Editfeld ein paar Sekunden später gefüllt wird, sollte es auch egal sein. Den ShiftLock bzw. ScrollLock Status, je nachdem welche Zifferntasten Du verwendest, solltest Du natürlich abfragen und wenn nötig kurzzeitig umschalten, weil das kann länger dauern, bis der Status sich ändert.

[gibb]

Mhmmm der zweite teil klingt ja mal ganz gut. Hätte ich auch selber drauf kommen können. Könnte den Wert als ungesendet markieren und beim nächsten durchlauf checken ob noch ungesendete werte vorhanden sind.

gruss sev der vom zweiten lösungsansatz sehr angetan ist. Manchmal sieht man vor lauter bäume den Wald nicht mehr. Danke viel mals für deine arbeit.

EDIT: Währe es nicht auch einen ansatz eine eigene postmessage zu implementieren welche SendInput mit implementiert? Also sozusagen ein Erweiterte Postmessage welche eine Kombination der beiden funktionen ist.

EDIT2: klar gehts nicht is ja ne winapi funktion -.-'

[gibb]

Delphi-Quellcode:

Syntax

WM_KEYDOWN

    WPARAM wParam
    LPARAM lParam;
    
Parameters

wParam
Specifies the virtual-key code of the nonsystem key. 
lParam
Specifies the repeat count, scan code, extended-key flag, context code, previous key-state flag, and transition-state flag, as shown in the following table. 
0-15
Specifies the repeat count for the current message. The value is the number of times the keystroke is autorepeated as a result of the user holding down the key. If the keystroke is held long enough, multiple messages are sent. However, the repeat count is not cumulative.
16-23
Specifies the scan code. The value depends on the OEM.
24
Specifies whether the key is an extended key, such as the right-hand ALT and CTRL keys that appear on an enhanced 101- or 102-key keyboard. The value is 1 if it is an extended key; otherwise, it is 0.
25-28
Reserved; do not use.
29
Specifies the context code. The value is always 0 for a WM_KEYDOWN message.
30
Specifies the previous key state. The value is 1 if the key is down before the message is sent, or it is zero if the key is up.
31
Specifies the transition state. The value is always zero for a WM_KEYDOWN message.

0-15 ist meiner Meinung nach noch interessant, könnte man damit das controle/Shift keyup nicht so häuffig nachsenden das es dann funktioniert?

Gruss Sev