Explizites tasten event auslösen

[gibb]

Hallo zusammen,

Ich mache folgendes:

Delphi-Quellcode:

procedure TSFontroler.UpdateFanSpeed(AFan : TFanOverlayObject);
var
  HWNDControl : HWND;
  i:Integer;
  wparam: smallint;
  strNewSpeed:String;
begin
  HWNDControl:= getControlHandle(AFan.ControleNumber);
  if Afan.NewSpeed <> -1 then begin
    if HWNDControl <> 0 then begin
      PostMessage(HWNDControl, WM_KEYDOWN, 46,0); // Delete taste runter
      PostMessage(HWNDControl, WM_KEYUP , 46, 0); // Delete taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 46,0); // Delete taste runter
      PostMessage(HWNDControl, WM_KEYUP , 46, 0); // Delete taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 46,0); // Delete taste runter
      PostMessage(HWNDControl, WM_KEYUP , 46, 0); // Delete taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 8,0); // Delete taste runter
      PostMessage(HWNDControl, WM_KEYUP , 8, 0); // Delete taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 8,0); // Delete taste runter
      PostMessage(HWNDControl, WM_KEYUP , 8, 0); // Delete taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 8,0); // Delete taste runter
      PostMessage(HWNDControl, WM_KEYUP , 8, 0); // Delete taste rauf
      strNewSpeed:= inttostr(AFan.NewSpeed);
      GPModLog.AddToLog('Speddfancontrole: fan'+ AFan.overlayName + ': ' + strNewSpeed );

      For i:= 1 to Length(strNewSpeed) do begin
        wparam:= MapIntToKey(strNewSpeed[i]);
        PostMessage(HWNDControl, WM_KEYDOWN, wparam,0); // Ctrl runter
    //    PostMessage(HWNDControl, WM_KEYUP , wparam, 0); //  Taste runter
      end;
    end;
  end;
end;

Function TSFontroler.MapIntToKey(akey: String) : Smallint;
begin
  Case StrToInt(akey) of
    0: Result:= 48;
    1: Result:= 49;
    2: Result:= 50;
    3: Result:= 51;
    4: Result:= 52;
    5: Result:= 53;
    6: Result:= 54;
    7: Result:= 55;
    8: Result:= 56;
    9: Result:= 57;
  End;
end;

So, der grund wieso postmessage mit dem keyUp event auskommentiert ist das der mir immer noch einmal eine Zahl hinzufügt. Scheint irgendwie mit dem lparam zusammen zu hängen... obwohl ich das nicht ganz verstanden habe was da sonst mit muss...

Ausserdem habe ich festgestellt das wenn ich das keyUp event weglasse und ich ctrl oder schift gedrückt halte auf der tastatur es diese messegas auch beinflusst... leider. Lässt sich das irgendwie umgehen? denn das programm läuft im hintergrund mit einem interval von 3 sec und jedesmal machts bing wenn ich die ctrl taste gedrückt halte :drunken:

Tja jetzt meine frage an euch 1. was sollte da bei lparam mit damit er mir nicht jedesmal beim keyup nochmal ein zeichen hinzufügt?
2. Was kann ich machen damit ctrl&co ignoriert wird?

Danke und Gruss
GIBB

[gibb]

Hallo

Keiner ne idee? mir währe es extrem wichtig zu wissen wie ich den einfluss von ctrl/Shift und andere dinge die manuell getätigt werden auf meine events unterbinden kann.

Das nervt wirklich ungemein... und ist sozusagen betriebsverhindernd.

Gruss GIBB

[shmia]

Versuchs doch mal mit der Unit SndKeys32: http://www.delphi3000.com/articles/article_1617.asp

[gibb]

Hi,
Danke für die anttwort. Leider hilft Sie mir nichts da ich die message direkt in ein spinedit einer anderen applikation sende. Das geht mit deiner Funktion leider nicht.
Nichtsdestotrotz danke vielmals. Hab mich gerade gefragt ob ich nicht irgendwie feststellen könnte ob zur Zeit gerade shift gedrückt ist und wenn ja dies schnell für 1ms deaktivieren und wieder aktivieren könnte.

Weitere Vorschläge her ;)

Gruss gibb

[shmia]

Also die Taste Control-S müsste doch so aussehen:

Delphi-Quellcode:

const
  LPARAM_KEYUP = $C000;  // Bit 31 & 30 gesetzt wie bei WM_KEYUP vorgeschrieben

PostMessage(HWND, WM_KEYDOWN, VK_CONTROL, 0);
PostMessage(HWND, WM_KEYDOWN, Ord('S'), 0);
PostMessage(HWND, WM_KEYUP, Ord('S'), LPARAM_KEYUP);
PostMessage(HWND, WM_KEYUP, VK_CONTROL, LPARAM_KEYUP);

Bringt dich das vielleicht weiter?

[gibb]

Hi, naja ganz verkehrt ist es nicht ^^'

aber ich will ja das NICHT controle und NICHT shift gedrückt ist wenn ich ne tasten eingabe mache... aber ev. hast du recht was der erste teil betrifft. Da ich zur zeit gerade mit ner trial version programmiere hab ich die hilfe nicht.

werds aber testen. ev wenn lparam stimmt dann hat er auch nicht mehr das gefühl das shift gedrückt ist. Mein kleiner hoffnungsschimmer ;)

Gruss gibb

[gibb]

mhmm, ich habe immer noch ein ungelöstes problem.

und zwar ctrl und die "^" taste haben dieselbe auswirkung wie die shift. Ich habe jetzt um das mit der shift taste zu umgehen einfach die werte vom Zahlenpad genommen. (die die mit numlock aktiviert werden) das funktioniert zwar bei shift aber beim resten noch nicht.

Also was mache ich das bei postmessage das useringaben ignoriert werden?

Gruss gibb

[gibb]

Hi,

irgendwie scheint für dieses problem niemand eine lösung zu kennen. Nun Folgende Idee was passiert wenn jemand gerade im word am schreiben ist und shift gedrückt hält, und ich immer ein keyup shift, ctrl usw. sende? Das wird ja nur an diesen handle gesendet oder?

gruss Sev

[idefix2]

Wenn Du unmittelbar hintereinander "shift loslassen", "Taste drücken", "Taste loslassen", "shift loslassen" schickst, sollte eigentlich nichts unerwümschtes passieren.

Es gibt übrigens die Funktion "sendinput", mit der eine Reihe von Tastatutereignissen mit einem einzigen API-Aufruf in die Messagequeue gestellt werden können, die sollten dann wirklich in jedem Fall unmittelbar hintereinander in der Queue stehen.


Nebenbei: Wäre statt

Delphi-Quellcode:

  Case StrToInt(akey) of
    0: Result:= 48;
    1: Result:= 49;
    2: Result:= 50;
    3: Result:= 51;
    4: Result:= 52;
    5: Result:= 53;
    6: Result:= 54;
    7: Result:= 55;
    8: Result:= 56;
    9: Result:= 57;
  End;

nicht einfacher

Delphi-Quellcode:

 Result := StrToInt (akey) + 48;

[gibb]

hi, hab das jetzt folgendermassen gelöst:

Delphi-Quellcode:

procedure TSFontroler.UpdateFanSpeed(AFan : TFanOverlayObject);
var
  HWNDControl : HWND;
  i:Integer;
  wparam: smallint;
  strNewSpeed:String;
begin

  HWNDControl:= getControlHandle(AFan.ControleNumber);
  if Afan.NewSpeed <> -1 then begin
    if HWNDControl <> 0 then begin
      PostMessage(HWNDControl, WM_KEYDOWN, 46,0); // Delete taste runter
      PostMessage(HWNDControl, WM_KEYUP , 46,  $C000); // Delete taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 46,0); // Delete taste runter
      PostMessage(HWNDControl, WM_KEYUP , 46,  $C000); // Delete taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 46,0); // Delete taste runter
      PostMessage(HWNDControl, WM_KEYUP , 46,  $C000); // Delete taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 8,0); // backspace taste runter
      PostMessage(HWNDControl, WM_KEYUP , 8,  $C000); // backspace taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 8,0); // backspace taste runter
      PostMessage(HWNDControl, WM_KEYUP , 8,  $C000); // backspace taste rauf
      PostMessage(HWNDControl, WM_KEYDOWN, 8,0); // backspace taste runter
      PostMessage(HWNDControl, WM_KEYUP , 8,  $C000); // backspace taste rauf
      strNewSpeed:= inttostr(AFan.NewSpeed);
//      GPModLog.AddToLog('Speddfancontrole: fan'+ AFan.overlayName + ': ' + strNewSpeed );

      For i:= 1 teo Length(strNewSpeed) do begin
        wparam:= MapIntToKy(strNewSpeed[i]);
        PostMessage(HWNDControl, WM_KEYUP , 17,  $C000);  // ctrl up
        PostMessage(HWNDControl, WM_KEYUP , 16,  $C000);  // shift up
        PostMessage(HWNDControl, WM_KEYDOWN, wparam, 0); // Ctrl runter
   //     PostMessage(HWNDControl, WM_KEYUP , wparam,  $C000); //  Taste runter
         PostMessage(HWNDControl, WM_KEYUP , 17,  $C000);  // ctrl up
        PostMessage(HWNDControl, WM_KEYUP , 16,  $C000);  // shift up
      end;
    end;
  end;
end;

Das ist wie es gelöst ist zur zeit... kanns leider gerade nicht testen, aber ihr denkt so sollte das gehen das shift und ctrl ignoriert wird? Ausserdem habe ich immernoch das Problem das es mir murks schreibt beim KeyUp resp. das er mir dieselbe zahl nochmals schreibt....

und doch das sieht viel einfacher aus ;)

gruss Sev

[himitsu]

Zitat:

Zitat von idefix2

Nebenbei: Wäre statt ... nicht einfacher ...

da

Zitat:

Code:

wparam := MapIntToKey(strNewSpeed[color=#ff0000][b][i][/b][/color]);

Delphi-Quellcode:

wparam := Ord(strNewSpeed[i]) + Ord('0');

oder gleich

Delphi-Quellcode:

PostMessage(HWNDControl, WM_KEYDOWN, Ord(strNewSpeed[i]) + Ord('0'), 0);

[idefix2]

Wozu soll das nochmalige ctrl-op und shft-up nach dem Tastendruck dienen?

[gibb]

das hab ich mich auch gefragt ;) aber ist von dir:
"shift loslassen", "Taste drücken", "Taste loslassen", "shift loslassen"

[idefix2]

Eben fällt mir ein - Wenn ich die Messages verfolge, die ein echter Tastendruck produziert, dann wird beim Keyup meistens $8000 und nicht $C000 als LPARAM erzeugt und an meine Hook-Routine übergeben. Das Bit 30 bezieht sich auf den vorherigen Zusatnd der Taste, ich weiss aber nicht sicher, wie der Wert wirklich genau sein muss.

Ich habe jetzt nicht nachgelesen und es nicht probiert, aber versuche doch einmal, das Keyup statt mit LPARAM=$C000 mit LPARAM=$8000 zu erzeugen, möglicherweise kommt dann keine zweite Ziffer nach.

-----

Ich habe gemeint danach nicht keyup, sondern keydown, damit der gleiche Status wie vor Deinen künstlichen Tastaturerignissen herrscht. Entschuldige, hab mich verschrieben.
Das ganze natürlich nur, wenn die Shift Taste tatsächlich gedrückt war, den Status liefert Dir vorher

ShftIsPressed := GetKeyState(VK_SHIFT) and $80 = 0;

Für ctrl analog


Nachdem die Messages nur an Dein eigenes Fenster gehen, ist das keydown danach wahrscheinlich ohnehin überflüssig, aber ganz sicher bin nicht.

[gibb]

Hi

Also hab das getestet.

1. das Piepsen kommt immer noch wenn ich ctrl oder shift drücke, das keyup ctrl hat also keinen einfluss!
2. Das Keyup event produziert auch mit $8000 als lparam weiterhin einen 2 ten tastendruck!

mhmm, was kann ich sonst noch machen?

gruss gibb

[gibb]

hi,

Ich hab folgendes gefunden:
http://www.delphitricks.com/source-c...oard_keys.html

was will er mir damit erklären=?
* NOTE:
* Setting the keyboard state will not work across applications
* running in different memory spaces on Win32 unless AttachThreadInput
* is used to connect to the target thread first.
*Created: 02/21/96 16:39:00 by P. Below

weil das hier klingt doch gut:
* Description:
* Uses keybd_event to manufacture a series of key events matching
* the passed parameters. The events go to the control with focus. <- scheisse aber kann man ja anpassen
* Note that for characters key is always the upper-case version of <- gut aber versteh leider nicht wie er das genau macht.
* the character. Sending without any modifier keys will result in
* a lower-case character, sending it with [ssShift] will result
* in an upper-case character!
*****************************

habs, wmkeyup muss als lparam $C0000000 mitgegeben werden damits funzt. Also das nur noch 1 Zahl entsteht =D

jetzt habe ich aber immer noch das Problem mit ctrl, shift und neu auch gefunden '^'

Sieht jemand wie er das umgeht?

Gruss gibb

[idefix2]

Delphi-Quellcode:

ShftGedrueckt := GetKeyState(VK_SHIFT) and 128 = 0; // Shift Status abfragen
CtrlGedrueckt := GetKeyState(VK_CTRL) and 128 = 0;  // Ich glaub die Taste heisst VK_CTRL

if ShftGedrueckt then keybd_event (VK_SHIFT, 0, KEYEVENTF_KEYUP, 0);
if CtrlGedrueckt then keybd_event (VK_CTRL, 0, KEYEVENTF_KEYUP, 0);
keybd_event (Taste,0,0,0)
keybd_event (Taste,0,KEYEVENTF_KEYUP,0)
if ShftGedrueckt then keybd_event (VK_SHIFT, 0, 0, 0);
if CtrlGedrueckt then keybd_event (VK_CTRL, 0, 0, 0);

[gibb]

GetKeyState(VK_SHIFT) and 128 = 0;
Das ergibt true auch wenn keine shift taste gedrückt ist ^^'

aber wofür ist das and 128=0 gut? diese bedingung ist ja immer False.... wie kann dann das result true sein?

gruss Sgibb

[idefix2]

GetKeyState(VK_SHIFT) liefert ein byte, in Bit 8 des Bytes ist der gedrückt-Status der Taste
mit "and 128" wird dieses Bit maskiert, Du kannst auch "and $80" schreiben, dann ist vielleicht noch klarer, was gemeint ist
wenn da null herauskommt war die Taste gedrückt,
wenn die Taste oben war, kommt 128 heraus, das ist <>0.

Schau Dir die Delphi-hilfe zu GetKeyState an

Du kannst auch Klammern setzen, wenn Dir die Operatorpriorität nicht unmittelbar klar ist. Der Ausdruck bedeutet

(GetKeyState(VK_SHIFT) and 128) = 0

und nicht

GetKeyState(VK_SHIFT) and (128 = 0)


Die Vergleichsoperatoren haben die niedrigste Priorität von allen Operatoren.

[gibb]

mhmm, das ganze gibt trozdem true zurück wenn shift nicht gedrückt ist.

Aber danke für die erklärung mit den klammern.

wie das mit dem Maskieren funktioniert habe ich nicht verstanden, kannst du mir hierzu das ganze einweig veranschaulichen?

ist das wie bei den Subnetzen wo mit der and operation das binäre verglichen resp. umgeschrieben wird?

einfach auf 128 abfragen dann stimmts, nur kommt der leider nie mehr raus aus dem shift/CTRL wenn der mal von meiner app gesetzt wurde...

Das einzige was hilft, die app manuell mit der maus beenden und ctrl, shift tasten links und rechts auf der tastatur zu drücken, sonst erholt der sich nimmer XD

[idefix2]

AND auf Bytes angewendet ist eine bitweise Operation:

Beispiel
Wenn in Variable a binär 11001100 (= 208)
und in Variable b binär 10101010 (= 170)
steht, ist a and b binär 10001000 (= 136)

Wenn Du a als Variable und b als Maske bezeichnet, dann liefert a and b als Ergebnis nur die gesetzten Bits der Variable a, die auch in der Maske b gesetzt sind. Dort, wo die Maske b 0-Bits hat, werden durch die AND Operation die entsprechenden Bits der Variablen "maskiert", also gelöscht. Kurz gesagt, in der maske sind die Bits gesetzt, die mich interessieren, durch die Maskierung werden die anderen Bits der Variablen, die mich nicht interessieren, null gesetzt.
x and 128 (binär 10000000, hex 80) maskiert mit Ausnahme des höchstwertige Bits alle Bits der Variablen, d.h. im Ergebnis ist nur dieses Bit gesetzt, wenn es in der Variablen gesetzt ist, und gelöscht, wenn es in der Variablen auch schon Null war, alle anderen Bits des Ergebnisses sind immer =0.

[gibb]

ah oke, dann ist es das was ich aus dem subneting noch in errinerung hatte ;)

Wer hätte gedacht das das wirklich benutzt wird XD

EDIT: Mhmm, also es scheint einwenig zufall zu sein welche ctrl/shift daste gedrückt und gelöst wird ob jetzt die rechte gedrückt wird oder die linke usw. is mist das ganze XD

[gibb]

jemand nen plan wieso das das so ist?

code sieht so aus:

Delphi-Quellcode:

        wparam:= MapIntToKey(strNewSpeed[i]);
     //   PostMessage(HWNDControl, WM_KEYUP , VK_CONTROL, $20000000);  // ctrl up
     //   PostMessage(HWNDControl, WM_KEYUP , VK_SHIFT, $10000000);  // shift up
        ShftGedrueckt := GetKeyState(VK_SHIFT) and 128 = 128; // Shift Status abfragen
        CtrlGedrueckt := GetKeyState(VK_CONTROL) and 128 = 128;  // Ich glaub die Taste heisst VK_CTRL
        if ShftGedrueckt then
          keybd_event (VK_SHIFT, 0, KEYEVENTF_KEYUP, 0);
        if CtrlGedrueckt then
          keybd_event (VK_CONTROL, 0, KEYEVENTF_KEYUP, 0);
        PostMessage(HWNDControl, WM_KEYDOWN, wparam, 0); // Ctrl runter
        PostMessage(HWNDControl, WM_KEYUP , wparam,  $C0000000); //  Taste runter
        if ShftGedrueckt then keybd_event (VK_CONTROL, 0, 0, 0);
        if CtrlGedrueckt then keybd_event (VK_CONTROL, 0, 0, 0);

und ist leicht zu testen, man braucht nur ne 2 te app macht und dort auf das formular ein edit postet findet diese funktion den handle des edits:

Delphi-Quellcode:

function TSFontroler.DebugHandle():hwnd;
var
  wndMain, wndChild: HWND;
begin
  wndMain := FindWindow('TForm1','Form1');
  if wndMain <> 0 then
  begin
    wndChild := FindWindowEx(wndMain, 0, 'TEdit', nil);
    if wndChild <> 0 then
    begin
      Result:= wndChild;
    end;
  end;
end;

wenn man zusätzlich das hier definiert:

Delphi-Quellcode:

procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: Char);
var
oldKey, newKey :Char ;
begin
  if  (key in [#48..#57, #8]) then     begin
   beep;
   FKeyList:= FKeyList + key;
  end else begin
    Key:= #0
  end;

end;

und bei postmessage eine zahl mitgibt. dann wird wenn man im else teil der funktion landet ctrl oder shift nicht ignoriert. weil dann aus der zahl einen nicht zahl charakter gemacht wird.

Mein Problem ist jetzt ja nicht mehr das ich im else teil lande sondern ctrl/Shift nicht mehr deaktiviert wird nach

Delphi-Quellcode:

        if ShftGedrueckt then keybd_event (VK_CONTROL, 0, 0, 0);
        if CtrlGedrueckt then keybd_event (VK_CONTROL, 0, 0, 0);

wenn ich anschliessend den ctrl/shift taste loslasse.

mfg Gibb

[idefix2]

Leider bin ich bei Deinem letzten Posting völlig ausgestiegen. Ich verstehe nicht, was die diversen Codeschnippsel konkret bewirken sollen, und auch nicht, was jetzt Dein konkretes Problem ist.

Was mir auffällt: Du mischt Postmessage mit keybd_event, ich habe keine Ahnung, ob sich die zwei auf die Art vertragen. Vielleicht solltest Du die CTRL und die SHIFT Taste auch mittels PostMessage schicken statt mit keybd_event - obwohl ich eigentlich glaube, dass das schon auch gehen müsste, und dass das nicht für Dein Problem verantwortlich ist. Ist auf jeden Fall nicht sehr schön, einheitlich wär sicher besser.

[gibb]

Also, der erste schnippsel ist dir ja bekannt, der kommt aus app1

der 2 te schnippsel ist um einen handle von einem edit auf einem Formular zu erhalten. Also nix weiteres machen als ne neue Delphi app erstellen und auf form1 ein edit posten ohne etwas anzupassen. (app2)


der 3 te schnippsel ist onkeypress vom edit auf dem Formular. ich prüffe ob das was ankommt ne Zahl ist und wenn nicht denn geht er in den Else teil. Er geht nur in den Else teil wenn ctrl gedrückt ist und du mit postmessage ne Zahl schickst.

jetzt mache ich nix anderes als von der app1 mit dem ersten schnippsel zahlen zu senden. wenn ctrl/Shift gedrückt wird lande ich bei app2 im breackpoint im else teil.

---------------------------------------

Problem ist nun folgendes, mache ich das so wie oben, verlässt er den ctrl/shift state nicht mehr wenn ich die ctrl/Shift taste danach wieder loslase(auf der tastatur) also es nur noch ein keyUp gibt.

Ich drücke auf der tastatur ctrl, app1 sendet ctrl up, app1 sendet zahl an app2, app1 macht ctrl down, ich lasse die ctrl taste los. Der Status von ctrl ist aber weiterhin gedrückt. bis ich auf der tastatur wieder ctrl down ctrl up mache und das auf der rechten seite des Keyboards links bringts nichts.

Ich hab dir die schnippel gemacht damit du das einmal testen kannst. ;)


---------------------------------------

"Was mir auffällt: Du mischt Postmessage mit keybd_event"

Ja dem ist so, da postmessage ctrl up keine auswirkung hat, zumindest so nicht wie ich es implementiert hatte.

und keybd_event nicht die zahl an einen Bestimmten handle senden kann. Daher der mix. Ist unschön, aber was will man machen wenns nur so "geht"

hoffe es hat sich geklärt.

gruss gibb

[idefix2]

ja, jetzt verstehe ich. Ich vermute, Du raufst mit einem ähnlichen Problem, das auch mir zu schaffen gemacht hat, nämlich dass die echten Tastenereignisse, wenn Tasten schnell gedrückt und losgelassen werden, die künstlichen Tastenereignisse, die durch früher erfolgte echte Tastenereignisse ausgelöst worden sind, überholen können. Ich nehme an, das "echte" Keyup vom wirklichen Loslassen der Taste taucht vor den künstlichen Events auf, deshalb ist am Ende der Tastenstatus unten und nicht oben.

Zum Überprüfen dieser Annahme: Halte einmal die Umschalttaste länger gedrückt, also bis wirklich alles angekommen ist, was am Ziffern-Tastendruck hängt, und lass danach erst die Umschalttaste los. Dann sollte sich das Ding so benehmen, wie Du es erwartest.

Ich habe das in meinem Programm so gelöst: Ich merke mir alle Tastenereignisse, die ich künstlich ausgelöst habe, in einer Liste (bzw. verwende ich der Einfachheit Halber einen String) und lösche ein Ereignis erst aus der Liste, wenn es wirklich eintrifft. Wenn diese Liste nicht leer ist, werden "echte" Tastaturereignisse - solche mit Scancode<>0 - nicht mehr durchgelassen, sondern sie werden geblockt und dafür künstlich erzeugt (und natürlich auch an die Liste der künstlich erzeugten Ereignisse angehängt). Auf die Art werden sie sicher hinter die anderen Ereignisse gereiht, und können früher erzeugte künstliche Ereignisse nicht überholen.

[gibb]

hi, ich merk gerade ich hatte gelogen was das funktionieren betrifft. es ist dennoch z.b. wenn ich 3 sende ein * wenn ich shift gedrückt halte :(((((

Und du hattest recht, der status stimmte nicht, also wenn ich wirklich das ganze nur 1 mal ausführe und warte mit dem keyup auf der tastatur bis das ganze 100% abgesetzt wurde bleibt auch ctrl/Shift nicht hängen.

Hilft jetzt aber dennoch nicht solange immernoch ein * ankommt :(

gruss Sev

[idefix2]

hmm, leider bin ich da jetzt auch ratlos. Vielleicht ist das Mischen von keybd_event und un postmessage doch nicht möglich, und es kommt dabei auch die reihenfolge durcheinander.

Du könntest Dir eventuell folgendes versuchen:

die Handle des fensters holen, das den Focus hat, und es dir merken
dann den Focus auf deine Control legen
dann alle Daten mit keybd_event an dein control schicken
und zuletzt dem anderen Control wieder den Focus geben

Viel mehr fällt mir dazu leider auch nicht ein. Vor allem weiss ich nicht, ob nicht doch etwas ganz anderes daran schuld ist, dass es nicht so tut, wie du willst.

[gibb]

hi,
der letzte vorschlag könnte zwar funktionieren aber da das programm im hintergrund läuft und alle sekunde schreibt währe das EXTREM mühsam wenn einem der fokus alle sekunde entzogen wird. Das ist definitiv keine Option.

Was ich mir aber gerade überlege, was macht ctrl genau? Wenn ctrl gedrückt ist wird da einfach aufadiert? also sowas du drückst die 3 das z.b. #50 entspricht jetzt ist controle noch gedrückt also entspricht das #50 + 24= #74 =* das sind alles fiktive werte!

Das frage ich weil man dann if shiftgedrückt then #50-#24 senden und ankommen tut dann #26+ #24 = #50= 3

machen könnte. und das OHNE ins ctrl/Shift focus reinzupfuschen.

gruss gibb

[idefix2]

Das mit dem Focus geht also offenbar nicht, verstehe ich. Ausserdem kann glaub ich nur ein Control den Focus bekommen, das sichtbar ist, und es wird automatisch in den Vordergrund gestellt, das wäre wohl auch ein Hindernis.

Zu Deiner Frage: Nein, das ist leider nicht so, Control aktiviert einfach ein anderes Layout für die Tastatur, jede einzelne Taste wird anders umgesetzt als ohne die Umschaltung. Im Moment weiss ich für Dein Problem leider auch keine Lösung, wenn mir etwas einfällt, melde ich mich wieder.

[gibb]

Danke jedenfalls für deine Hilfe :thumb:

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