Key-Code Ziffer Null

[TomyN]

Manchmal passieren seltsame Sachen.

Ich habe in meiner Software eine Art Taschenrechner, bei der entweder mit Tasten oder über die Tastatur Zahlen eingegeben werden können.
Eigentlich trivial, die Hauptarbeit passiert hier

Code:

 case key of
      ord('0'), VK_NUMPAD0: AddChar('0');
      ord('1')..ord('9'): AddChar(Char(key));
      VK_NUMPAD1: AddChar('1');
      VK_NUMPAD2: AddChar('2');
      VK_NUMPAD3: AddChar('3');
      VK_NUMPAD4: AddChar('4');
      VK_NUMPAD5: AddChar('5');
      VK_NUMPAD6: AddChar('6');
      VK_NUMPAD7: AddChar('7');
      VK_NUMPAD8: AddChar('8');
      VK_NUMPAD9: AddChar('9');

      VK_BACK:    ResetMe();
      VK_DELETE:  RemoveChar();
      VK_ESCAPE:  HideMe();
      VK_RETURN:  HideMe();
    end;

AddChar wertet das ganze aus.

Bei mir läuft es wunderbar, jetzt hat sich aber eine Kunde aus China gemeldet, bei dem alle Eingaben, bis auf die Ziffer 0 funktionieren. Die 0 funktioniert nicht, weder über die virtuelle Taste noch über die 0 auf der Tastatur (Num-pad hat er keines). Jetzt habe ich ihm ein kleines Programm geschrieben, dass die key-codes in ein Memo loggt. Da liefert die Ziffer Numm immer $00 30, wie auch bei mir. Irgendeine Idee, woran das liegen könnte?

Tomy

[himitsu]

Bist du denn sicher, dass dein AddChar richtig funktioniert?

Nja, ein Logging im "richtigen" Programm bringt wohl mehr.
Eventuell, fängt irgendeine andere Komponente/Funktion die 0 ab und sie kommt garnicht erst in deiner EventMethode an?
Dass "einfache" minimalistische Testprogramme manchmal/oftmals ein klein bissl anders arbeiten/reagieren, als wie ein hochkomplexes Programm, wo sehr viel Code/Komponenen drin arbeiten, das könnte man sich vielleicht denken.

PS:
Warum ist die 0 denn hier anders behandetl, als wie alle Anderen?

Delphi-Quellcode:

case key of
  ord('0')..ord('9'): AddChar(Char(key));
  VK_NUMPAD0: AddChar('0');
  VK_NUMPAD1: AddChar('1');
  VK_NUMPAD2: AddChar('2');
  VK_NUMPAD3: AddChar('3');
  VK_NUMPAD4: AddChar('4');
  VK_NUMPAD5: AddChar('5');
  VK_NUMPAD6: AddChar('6');
  VK_NUMPAD7: AddChar('7');
  VK_NUMPAD8: AddChar('8');
  VK_NUMPAD9: AddChar('9');
  VK_BACK:   ResetMe();
  VK_DELETE: RemoveChar();
  VK_ESCAPE: HideMe();
  VK_RETURN: HideMe();
end;

Wobei, wenn schon '0'..'9' zusammen, warum dann nicht auch VK_NUMPAD0..VK_NUMPAD9

Delphi-Quellcode:

case Key of
  Ord('0')..Ord('9'):     AddChar(Char(Key));
  VK_NUMPAD0..VK_NUMPAD9: AddChar(Char(Key - VK_NUMPAD0 + Ord('0')));
  VK_BACK:   ResetMe();
  VK_DELETE: RemoveChar();
  VK_ESCAPE, VK_RETURN: HideMe();
end;

[TomyN]

Nun ja, auch wenn ich es nicht müsste, hier meine 'Verteidigungsrede'.

Die Null wird extra behandelt, weil ursprünglich eine Sonderbehandlung der Null geplant war (diese ist aber noch nicht realisiert). So soll zum Beispiel eine 'Doppelnull' am Anfang des Strings vermieden werden.

In meinen Augen ist der Vorteil der Verwendung von benannten Konstanten der, dass man sich bei einer Änderung der Zahlenwerte keine Gedanken machen, bzw. nur die Definition ändern muss. Daher verlasse ich mich ungern auf Annahmen (wobei die Annahme, dass VK_NUMPAD_0 bis VK_NUMPAD_9 ohne Zwischenraum und in aufsteigender Reihenfolge definiert sind und immer bleiben werden, doch recht wahrscheinlich ist) über eine Reihenfolge oder eines Absolutwertes einer benannten Konstante.

Tomy

[Moombas]

Da wäre ggf. die Auswertung deines "AddChar" interessant, wenn die "0" dort richtig ankommt, muss der Fehler ja da drinnen passieren.

[TomyN]

Ja.... wenn man sich auf den Kunden verlässt. Das Problem lag nicht an der Null sondern dran, dass keine zweite Ziffer möglich war. Er hat nur immer versucht eine Null einzugeben.

Ansonsten bleibt mir das ganze immer noch etwas rätselhaft. Ich bin mit Regulären Ausdrücken nicht so vertraut und wollte es mal versuchen. Der Zweck war, zu erkennen wenn ein zweites Mal ein Dezimaltrenner eingegeben wird und das zu verhindern.

Code:

 i:= TRegEx.Matches(myValueString, formatSettings.DecimalSeparator).Count;
 if (i > 1) then begin
   //Wir haben zwei DS...
   SetLength(myValueString, Pred(Length(myValueString)));
 end;

Allderdings war i beim Kunden immer zwei, wenn der String 2 Zeichen lang wurde, so dass er immer gekürzt wurde. Bei mir gab es keinerlei Probleme.

Tomy

[himitsu]

Kann man den Punkt nur am Ende eingeben?

Also Grundsätzlich ist es einfacher "Ungültiges" garnicht erst ins Edit reinkommen zu lassen.
-> Wenn Key='.' und ein Punkt bereits vorhanden, dann Key:=0; (eventuell das Ganze bereits im OnKeyDown, anstatt im OnKeyPress)



PS: Sobald das Edit nicht ReadOnly/Disabled ist und die Eingaben ausschließlich durch deinen Code in der Anzeige landen:

Im Notpade den Text "....." mit Strg+C abholen
und dann via Strg+V, Shift+Einfg, Kontextmenü oder sonstwie in dein Edit rein.

Schon hast du viele Punkte und dein "bei . prüfen ob schon vorhanden" hat nix mitbekommen.
Im OnChange könnte man sowas zusätzlich/sichrer prüfen und dann das "Böse" rauslöschen.
Alternativ im OnChange nur Prüfen und das Edit nur "rot" malen, und eine Fehlermeldung/Exception erst bei anschließender Verarbeitung, um den Eingabefluss nicht zu stören.



Ach ja, statt RegEx hier eher ein TStringHelper.CountChar
oder die "billige" alte Variante ala Anzahl := Length(myValueString) - Length(ReplaceStr(myValueString, '.', ''));

[TomyN]

Hallo,

Welches Edit siehst Du denn? Ich fange die Tastendrücke ab und bastel mir den String indem ich das zuletzt eingegebene Zeichen hinten anhänge. Reinkommen da nur die Zahlen sowie der Decimalseparator.

Tomy