Auf Ende der Eingabe im TEdit warten und Inhalt verzögert verarbeiten

[hoika]

Hallo,
wir haben das über einen Timer gelöst.
Jedes OnKeypress setzt den Timer zurück.
Ein Timer-Intervall von 600 msec sorgt dann dafür,
dass nach 600 msec Nichteingabe eines Zeichens das OnTimer aufgerufen
und dort drin dann die Suche gestartet wird.

Man könnte das ganze auch "verzögerte Suche" nennen.

[jaenicke]

Ich möchte bei solchen Livefiltern als Benutzer allerdings nicht länger warten als nötig. Zudem fühlt es sich einfach moderner an, wenn man die Ergebnisaktualisierung direkt beim Tippen sieht.

Deshalb verzögere ich selbst solche Filterungen nur, wenn die Ergebnismenge noch zu hoch ist oder die Suche mehr als wenige Millisekunden dauert.

[Bernhard Geyer]

Zitat von hoika:

Ein Timer-Intervall von 600 msec sorgt dann dafür,
dass nach 600 msec Nichteingabe eines Zeichens das OnTimer aufgerufen
und dort drin dann die Suche gestartet wird.

Man könnte das ganze auch "verzögerte Suche" nennen.

Machen wir ähnlich. Glaube aber wir haben einen kleineren Wert für das Timer-Intervall.

Zitat von jaenicke:

Deshalb verzögere ich selbst solche Filterungen nur, wenn die Ergebnismenge noch zu hoch ist oder die Suche mehr als wenige Millisekunden dauert.

Man könnte auch das Ergebnis immer auf x Ergebnisse beschränken und am Ende einen Eintrag "Weitere Ergebnisse Vorhanden" anzeigen.

[dummzeuch]

Wir benutzen auch einen Timer, der bei jedem Tastendruck zurückgesetzt wird. Wenn ich mich recht erinnere, steht er auf 500 ms (1/2 Sekunde). Bisher hat sich noch keiner darüber beschwert (zumindest nicht bei mir).

In unserem Fall geht es darum, zu überprüfen, ob die Eingabe der Name einer existierenden Datei bzw. eines existierenden Verzeichnisses ist. Da das teilweise zu Zugriffen auf das LAN führt und einen langen Timeout nach sich ziehen kann, wenn der Rechner, auf den zugegriffen wird, nicht eingeschaltet ist, sorgt diese Verzögerung dafür, dass man weniger warten muss als wenn bei jedem Tastendruck geprüft würde.

Beispiel:

\\server1\share\bla\blub.txt

existiert nicht, aber

\\server2\share\bla\blub.txt

schon. Der User hat sich schlicht vertippt bzw. einen falschen Pfad per Zwischenablage eingefügt. Wenn er jetzt "schnell genug" (1 Tastendruck pro 500 ms ist nicht besonders schwierig) den Fehler korrigiert, erspart es ihm die mehrere Sekunden Timeout, die die Prüfung auslösen könnte.

[Bünni]

Zitat:

Jedes OnKeypress setzt den Timer zurück.

Danke für eure Antworten. Meint ihr mit Timer einen einfachen TTimer? Was genau meint ihr mit zurücksetzen?

[Bernhard Geyer]

Zitat von Bünni:

Zitat:

Jedes OnKeypress setzt den Timer zurück.

Danke für eure Antworten. Meint ihr mit Timer einen einfachen TTimer? Was genau meint ihr mit zurücksetzen?

Ja. Normaler TTimer.
Und bei OnkEyPress ein

MyTimer.Active := False;
MyTimer.Active := True;

Damit staten dann die xxx ms neu.

[Bünni]

Die Technik wurde erfolgreich eingebaut.
Die erste Testperson war meine Lebensgefährtin und sie bevorzugt die Suche mit sofortigem Ergebnis.
Grund sei, sie kenne eine solche verzögerte Suche nicht und sie sei langsam. Der Timer wird im OnChange zurückgesetzt und die Verzögerung beträgt 500ms.
OnChange, weil er dann auch zurückgesetzt wird, wenn ich das Edit.Text Property per Code setze und nicht durch manuelle Eingabe.


Welche Methode ist heutzutage die von Benutzern eher akzeptierte Methode?

[dummzeuch]

Zitat von Bünni:

Der Timer wird im OnChange zurückgesetzt und die Verzögerung beträgt 500ms.
OnChange, weil er dann auch zurückgesetzt wird, wenn ich das Edit.Text Property per Code setze und nicht durch manuelle Eingabe.

Du solltest ihn auch bei OnKeyDown zurücksetzen, sonst werden Tastendrücke, die nur den Cursor bewegen, nicht berücksichtigt.

[jaenicke]

Zitat von Bünni:

Welche Methode ist heutzutage die von Benutzern eher akzeptierte Methode?

Ich glaube nicht, dass ein Benutzer warten will. Diese verzögerten Suchmasken wurden ja nicht gemacht, weil es so sein soll, sondern weil es technisch eben nicht anders ging.

Heute sind die PCs schneller, so dass es meistens keine Notwendigkeit mehr dafür gibt.

Im Falle unseres Background-Compilers z.B. geben wir Änderungen live an den Compilerthread weiter, wobei dann die dadurch ungültigen Teile wieder verworfen werden. Insgesamt sind so die Eingabehilfen aber sehr schnell da.

Bei blockierenden Anfragen an Dateisysteme oder Webservices verwenden wir stattdessen tatsächlich jeweils einen neuen Thread, damit die GUI bei Fehleingaben nicht blockiert wird.