ConsoleKeyInfo, das Fragezeichen und die Portabilität

8

Ich habe eine kleine C # -Konsolenanwendung, die einen Schlüssel liest und prüft, ob der Schlüssel ein Fragezeichen ist:

%Vor%

Ich bin bei Oem2 angekommen, indem ich gesehen habe, welcher Wert tatsächlich im Debugger zugewiesen wird, weil es kein ConsoleKey-Code für Fragezeichen.

Nun könnte ich natürlich ki.KeyChar verwenden, aber die Anwendung muss auch auf bestimmte Schlüssel (z. B. Medienschlüssel) antworten, die nicht Zeichen zugeordnet sind. Es fühlt sich unelegant an, sowohl ConsoleKey als auch KeyChar zu überprüfen, um festzustellen, welcher Schlüssel tatsächlich gedrückt wurde. Auf der anderen Seite ist es nicht sicher, sich darauf zu verlassen, dass Oem2 immer in allen Umständen und Regionen auf ? abgebildet wird.

Ist es die beste Vorgehensweise, beide Eigenschaften zu prüfen, um festzustellen, welcher Schlüssel tatsächlich gedrückt wurde?

Es wird geschätzt, warum ConsoleKeyInfo auf diese Weise entwickelt wurde.

    
Eric J. 28.02.2012, 20:22
quelle

3 Antworten

6

In diesem Fall müssen Sie KeyChar == '?' überprüfen. Von MSDN :

  

Oem2: Der OEM-2-Schlüssel (OEM-spezifisch).

Du hast also nur Glück, dass es zufällig ein ? auf deiner Ausrüstung ist.

Die ConsoleKeyInfo -Struktur bietet KeyChar (ein Char -Wert) ) sowie Modifiers (eine Aufzählung), damit Sie entscheiden können, welche Tasten der Benutzer gedrückt hat.

    
Yuck 28.02.2012, 20:32
quelle
2

Ich denke, Sie sollten überlegen, was passiert, wenn jemand ein anderes Tastaturlayout hat.

Wenn Sie nach dem Schlüssel mit Fragezeichen auf meinem Computer suchen möchten, verwenden Sie ConsoleKey . Aber das ist wahrscheinlich keine gute Idee und Sie sollten sich wahrscheinlich an die Benutzereinstellungen halten und KeyChar verwenden.

Aber für Schlüssel, die den Zeichen nicht zugeordnet werden (und der Benutzer kann sie nicht neu zuordnen, indem sie ein anderes Tastaturlayout verwenden), müssen Sie ConsoleKey verwenden.

Also, ja, ich denke, Sie sollten in diesem Fall beide Eigenschaften überprüfen.

    
svick 28.02.2012 20:37
quelle
2

Ich vermute, der Grund für dieses Design ist, dass Console.ReadKey() auf einer nativen Funktion beruht ( ReadConsoleInput ), die ein Array von KEY_EVENT_RECORD Strukturen im Falle eines Tastendrucks, wobei jedes Schlüsselereignis eine ASCII / Unicode-Zeichendarstellung und ein virtueller Schlüsselcode . Beachten Sie die VK_OEM_2 in meinem vorherigen Link - hier kommt der ConsoleKey.Oem2 -Wert.

    
Yuriy Guts 28.02.2012 20:46
quelle

Tags und Links