SendInputHelper - Ein Wrapper, der den Umgang mit SendInput vereinfacht

[WladiD]

Zitat von PeterPanino:

Nachdem ich eine Lösung für das TShiftState-Problem aufgezeigt habe, habe ich jetzt endlich den Fehler gefunden, bei dem keine Akzentzeichen (z.B. éèáà usw.) ausgegeben wurden. Ich habe jetzt die Delphi XE3 IDE zum Debuggen verwendet, und die stürzt im Debug-Modus nicht ab, obwohl AQtime installiert ist!

Delphi-Quellcode:

if not((Ord(SendChar) > 0) and (Ord(SendChar) < 127)) then // war: 255
begin
  Result := GetUnicodeChar(SendChar, Press, Release);
  Exit;
end;

Der Fehler liegt darin, dass Waldemar die Unicode-Zeichenbehandlung erst ab Ord(SendChar) = 255 angesetzt hat. Akzentzeichen wie é sind jedoch auf einer deutschen Tastatur mit den Umschalttasten Shift/Ctrl/Alt(/AltGr) nicht erreichbar (und nur diese sind im Rückgabewert von VkKeyScan kodiert), deshalb hat das nachfolgende VkKeyScan(SendChar) immer einen falschen ScanCode von 65535 (!) ergeben, wodurch natürlich kein Zeichen gesendet wurde. Die deutschen Umlaute sind zwar auch 8-bittig kodiert (haben also einen ASCII-Wert im Bereich 128-255), sind jedoch mit den Umschalttasten auf einer deutschen Tastatur erreichbar und liefern deshalb bei VkKeyScan einen korrekten Wert zurück. Bei Verwendung einer US-Tastatur würde VkKeyScan aber auch bei den deutschen Umlauten einen falschen Wert zurückgeben. Es ist also richtig, bei VkKeyScan vom kleinsten gemeinsamen Nenner - nämlich 7-bit ASCII - auszugehen!

Hi PeterPanino,

sicherlich ist es nach all den Jahren nicht mehr relevant, aber ich wollte hier mal erwähnen, das dieser Fehler jetzt beseitigt ist. Auch habe ich das Set TShiftState nach TSIHShiftState umbenannt, damit es keine Namenskonflikte mit anderen Bibliotheken geben kann.

Das Repository befindet sich schon seit einigen Jahren auf GitHub:
https://github.com/WladiD/SendInputHelper

[KodeZwerg]

Zitat von WladiD:

sicherlich ist es nach all den Jahren nicht mehr relevant, aber ich wollte hier mal erwähnen, das dieser Fehler jetzt beseitigt ist. Auch habe ich das Set TShiftState nach TSIHShiftState umbenannt, damit es keine Namenskonflikte mit anderen Bibliotheken geben kann.

Sorry für's hochpushen aber ich möchte mich bedanken für diesen Beitrag der mir echt gut gefallen hat! Das mit den Arrays war wirklich eine Qual, dank Dir nun nicht mehr!

[PeterPanino]

DANKE nochmals für SendInputHelper - einfach nützlich und genial!

[WladiD]

Zitat von PeterPanino:

DANKE nochmals für SendInputHelper - einfach nützlich und genial!

Danke! Das geht runter wie Öl.

[PeterPanino]

Zitat von WladiD:

Zitat von PeterPanino:

DANKE nochmals für SendInputHelper - einfach nützlich und genial!

Danke! Das geht runter wie Öl.

Ich habe SendInputHelper neulich in einem wichtigen Projekt verwendet - es funktioniert zum Glück auch mit Unicode!! Was will man mehr?

Es sind solche Programmierer wie Waldemar Derr, die mit ihrer ausgezeichneten Arbeit Delphi voranbringen!

[himitsu]

Wenn beim Add oder Flush eine Exception auftreten könnte, dann würde noch der Ressourcenschutzblock fehlen.

Delphi-Quellcode:

with TSendInputHelper.Create do
  try
    AddShortCut([ssWin], 'r'); // [Win] + [R]
    AddDelay(100); // Verzögerung in ms
    AddText('cmd', TRUE); // TRUE = AppendReturn
    Flush; // Erst hier werden die zuvor hinzugefügten Eingaben gebündelt abgesetzt.
  finally
    Free;
  end;

Wenn du das auf einen Record umschreibst und z.B. intern nur dynamische Arrays (anstatt objekte/Pointer/Listen) verwendets,
OK, ein Interface statt Class ginge auch, aber warum komplizierter.

dann kann man auf Create und Free verzichten, also wie eine einfach Variable benutzten und dann vergessen. (wie Integer, TPoint oder String+StringHelper)

PS, dann ginge auch sowas wie Ducktyping. (überall jeweils Self als Result zurückgegeben)
TSendInputHelper.Create.AddShortCut([ssWin], 'r').AddDelay(100).AddText('cmd', TRUE).Flush;


Ja, Dank Custom-Managed-Records kann man nun auch in Records eigentlich alles benutzen,
so lange ein Record nur sein eigenens Zeugs nutzt und man beim Kopieren von Variablen alle Inhalte, anstatt nur die Referenzen kopiert,
oder man für Objekte/Pointer sich eine Referenzzählung baut (geht, aber macht kein Spaß, da es keine Record-Vererbung gibt und Generics hier kaum nutzbar sind).


Warum eigentlich .Flush und nicht .Send ?

[PeterPanino]

Zitat von himitsu:

Wenn beim Add oder Flush eine Exception auftreten könnte, dann würde noch der Ressourcenschutzblock fehlen.

Delphi-Quellcode:

with TSendInputHelper.Create do
  try
    AddShortCut([ssWin], 'r'); // [Win] + [R]
    AddDelay(100); // Verzögerung in ms
    AddText('cmd', TRUE); // TRUE = AppendReturn
    Flush; // Erst hier werden die zuvor hinzugefügten Eingaben gebündelt abgesetzt.
  finally
    Free;
  end;

Wenn du das auf einen Record umschreibst und z.B. intern nur dynamische Arrays (anstatt objekte/Pointer/Listen) verwendets,
OK, ein Interface statt Class ginge auch, aber warum komplizierter.

dann kann man auf Create und Free verzichten, also wie eine einfach Variable benutzten und dann vergessen. (wie Integer, TPoint oder String+StringHelper)

PS, dann ginge auch sowas wie Ducktyping. (überall jeweils Self als Result zurückgegeben)
TSendInputHelper.Create.AddShortCut([ssWin], 'r').AddDelay(100).AddText('cmd', TRUE).Flush;


Ja, Dank Custom-Managed-Records kann man nun auch in Records eigentlich alles benutzen,
so lange ein Record nur sein eigenens Zeugs nutzt und man beim Kopieren von Variablen alle Inhalte, anstatt nur die Referenzen kopiert,
oder man für Objekte/Pointer sich eine Referenzzählung baut (geht, aber macht kein Spaß, da es keine Record-Vererbung gibt und Generics hier kaum nutzbar sind).

Kannst du bitte mal ein paar Code-Beispiele zeigen?