FS#4258 - Fehlerhafte Wertevalidierung lässt GUI einfrieren
Eine fehlerhafte Validierung der Eigenschaften eines Nodes im IA lässt die GUI unbedienbar werden. Weder ein Abbrechen, noch ein schließen des Fensters ist möglich, bis der Wert entsprechend korrigiert wurde. Für mich als User ist nicht erkennbar, warum das UI unbedienbar wird.
Vorschlag: zulassen des “Abbrechen” Button sowie schließen des Fensters und einblendung eines Tooltips mit einem Hinweis auf fehlerhafte Werteingabe inkl. dem zulässigen Wertebereich (Angelehnt an das Verhalten im Device Control).
Beispiel für das “einfrieren” Eingabe eines negativen Wertes für das Delay Node.
Hier sollte idealerweise ein ToolTip angezeigt werden, ähnlich dem Device Control.
- Tooltip wird angezeigt, jedoch siehe unten
- ESC funktioniert
- Cancel funktioniert nicht
In der englischen Version der Software gibt es im Tooltip deutschen Text
Bei mir funktioniert ESC um den Wert zurück zu setzen. Kann das gerade leider nicht reproduzieren. Der 1. ESC Klick lässt den ToolTip verschwinden, der 2. Stellt den alten Wert wieder her. Das ist aber das normale Verhalten von dem Control. Das da Deutscher Text steht, liegt daran, dass der zugrundeliegende Fehler von Windows anhand der Windows Spracheinstellungen übersetzt wird. Das ist ein Problem, für das wir noch keine wirklich gute Lösung gefunden haben.
Das Problem, was ich hier sehe ist, dass ESC zwar die Eingabe wieder zurück setzt, aber man nicht mitbekommt, dass die Eingabe falsch war. Deshalb wirkt es so, als wäre die GUI eingefrohren. Wenn jmd. den Tooltip deaktiviert hat, dann bekommt er es gar nicht mit.
Ich kenne das aus anderen Programmen so, dass beim bestätigen mit Enter und einer falsch Eingabe der gesamte Text einfach markiert wird. Wenn man was anderes selektiert wird der Wert zurück gesetzt.
Weiß nicht ob das möglich ist…
Das funktioniert bei mir genauso. Ich gebe einen falsche Eingabe, drücke Enter. Boom, Tooltip kommt hoch wie in dem Screenshot. Wenn ich dann ESC drücke, ist die gesamte Eingabe markiert und ich muss die ändern, oder eben durch 2. ESC zurücksetzen.
Von daher weiß ich echt nicht wo hier das Problem ist, bzw. falls es eins gibt ist es bei mir nicht reproduzierbar.
Das ESC drücken finde ich aktuell intuitiv. Woher soll man wissen, dass man ESC drücken soll um die Falscheingabe zu quittieren…
Cancel funktioniert nicht, wenn noch ein nicht zugelassener Wert in einem Feld steht, bis er mit ESC (oder durch Eingabe) durch einen zugelassenen Wert ersetzt wird. Könnte man durch Klicken auf Cancel automatisch den alten Wert wiederherstellen (damit sich das Fenster schließt), wenn der neue Wert nicht zugelassen wird?
@Joseph
Das ist das Standardverhalten von diesem Control in Windows. Außerdem zeigen wir das im Tooltip an, dass man mit ESC den alten Wert herstellen kann. Da steht das drinne. Evtl. hast du dir die Tooltips abgeschaltet.
@Johannes
Auch das ist normales Standard verhalten. Der Fokus bleibt auf dem Control, bis ein gültiger Wert eingegeben ist. Anstelle von Cancel kann man einfach 2x ESC drücken, dann wird der alte Wert wiederhergestellt und das Fenster geschlossen.
"Auch das ist normales Standard verhalten. Der Fokus bleibt auf dem Control, bis ein gültiger Wert eingegeben ist."
Auch wenn das Standardverhalten ist, find ich es nicht gut :D Deshalb hab ich es ja hierher geschrieben. Dem Namen nach sollte Cancel alles bisher veränderte Abbrechen, das tut es hier aber ja nur bedingt.
Wie ihr es am Schluss programmiert müsst ihr selber wissen, aber das ist halt mein Senf dazu
Verstanden, es ging mir nicht darum deine Meinung in Frage zu stellen, sondern mehr um den Hinweis, dass dieses Verhalten nicht von uns kommt, sondern von Microsoft.
also für mich ist es ersichtlich jetzt das dort ein Bedienfehler des Users vorliegt. Bei Falscheingabe kommt erst der Tooltip und selbst wenn man ihn druch ESC oder durch klicken weg bekommt, bleibt die Falscheingabe immer noch makiert und wartet auf dem richtigen Wert. Gut "Ok" und "Abbrechen" kann man anklicken aber ohne Funktion und oben ist immer noch die Falscheingabe makiert, so sollte für jeden ersichtlich sein das dort ein Fehler ist, der koridiert werden sollte durch den richtigen Wert.
Gemäß QRM-Meeting vom 16.03.2021 wird folgendes vereinbart: