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

[Bünni]

Ich bin mir nicht mehr ganz sicher woher ich das Verhalten kenne welches ich unten erkläre. Aber ich hoffe ich erkläre es verständlich.
In meinem Programm gibt es ein TEdit und es dient als Eingabe für eine Suchmaske. Ein Filter entscheidet dann welche VST Knoten angezeigt werden sollen und welche nicht.

Der Filtercode ist schnell aber ich würde gerne unnötige Aufrufe vermeiden. Die Eingabe von A, B und danach C, also ABC, ruft die Filtermethode dreifach auf und die Nodes werden dreifach gefiltert.

Ich würde gerne wissen, ob es eine Möglichkeit gibt auf das Ende der Eingabe zu warten und dann erst den Filter aufzurufen.
Das Event OnExit kommt wegen Gründen der Benutzerunfreundlichkeit leider nicht in Frage.

Hier wird ein Thread als Lösung vorgeschlagen. Bei jeder neuen Eingabe ins Edit wird der aktuelle Thread gekillt und ein neuer erstellt.
Das ist meiner Meinung nach aber kontraproduktiv und kostet sogar noch mehr Zeit. https://stackoverflow.com/questions/...r-still-typing

[Luckie]

Das Programm muss ja wissen, wann die Eingabe beendet ist. Da es nicht hellsehen kann, muss es der Benutzer dem Programm mitteilen. Also die Suche erst auslösen, wenn der Benutzer Return oder so gedrückt hat.

[olaf]

Zähl doch einfach die Buchstaben die der User eingibt und lege in Deiner Software ein Wert fest ab wann die Abfrage ausgeführt werden soll. Bei einem Wert von 3 werden nach 3, 6, 9 … Abfragen ausgeführt.

[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:

Zitat von hoika (Beitrag 1429724)

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:

Zitat von jaenicke (Beitrag 1429726)

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:

Zitat von Bünni (Beitrag 1429733)

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:

Zitat von Bünni (Beitrag 1429740)

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:

Zitat von Bünni (Beitrag 1429740)

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.

[Bünni]

Wenn das erlaubt ist, würde ich dafür gerne ein neues Thema öffnen. Das könnte eine sehr interessante Diskussion werden.

[Luckie]

Ok, die Idee mit dem Timer ist natürlich eine Lösung auf die ich nicht gekommen bin.

[hoika]

Hallo,
entscheiden tut der Anwender.
Wenn 500 zu langsam, nimm einen kleineren Wert.

[ConnorMcLeod]

Mach den Verzögerungswert einfach optional einstellbar - bei Null wird nicht gewartet und gut ist (siehe Systemsteuerung/Tastatur). Es gibt Szenarien, in denen das sehr sinnvoll ist und ich hatte es auch mal mit einem Timer gelöst; ein Thread wäre mglw eleganter, aber zuviel Aufwand im Verhältnis. IMHO.

[jaenicke]

Zitat:

Zitat von ConnorMcLeod (Beitrag 1429795)

ich hatte es auch mal mit einem Timer gelöst; ein Thread wäre mglw eleganter, aber zuviel Aufwand im Verhältnis. IMHO.

Ich halte hier einen Thread nicht für eleganter, im Gegenteil. Das Zurücksetzen des Timers ist kostengünstig und ein Timer ist auch genau dafür gedacht nach einer bestimmten Zeit etwas auszuführen.

[Rollo62]

Ich benutze für sowas auch gerne Timer.

Weil ich seit Win95 oder WinXP aber immer das Damoklesschwert von "zu wenig vorhandenen Timer-Resourcen" im Hinterkopf habe, bleibt da immer ein ungutes Gefühl bestehen.

Vielleicht kann mich jemand da jemand beruhigen, dass sowas in modernen Systemen nicht mehr auftreten kann
(Natürlich rede ich nicht davon wenn man irgendwo massiv zig-tausende Timer verwenden würde,
sondern von einem normalen Fall von Timer in einer handvoll Units).

Unter welchen Umständen würde wohl so ein Timer nicht korrekt feuern ?

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1429814)

Vielleicht kann mich jemand da jemand beruhigen, dass sowas in modernen Systemen nicht mehr auftreten kann

Raimond Chen kann das vermutlich: What is the maximum number of timers a program can create?

[Rollo62]

Dankeserh für den Link.
So ganz beruhigt bin ich leider noch nicht :stupid:
Wer weiss schon wieviel Timer Delphi, 3rd PArty, o.ä. intern nutzen ?

Für generelle Timing-Verzögerungen habe ich mir einen "DelayWorker" gebaut,
mit einem Timer der mehrere anonyme Procs in der richtigen Sequenz feuern kann.
Damit bin ich dann wohl doch auf der sichereren Seite.

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1429814)

(Natürlich rede ich nicht davon wenn man irgendwo massiv zig-tausende Timer verwenden würde,
sondern von einem normalen Fall von Timer in einer handvoll Units)

Ich habe hier ein Alt-System, da laufen ca. 80 Timer gleichzeitig ohne Probleme. Es ist dabei viel wichtiger die Intervalle an die benötigen Event-Laufzeiten anzupassen, als über eine Handvoll Timer mehr oder weniger nachzudenken

[Delphi.Narium]

Einfachste Methode:

Timer am Anfang des Ereignisses ausschalten und am Ende wieder einschalten.

Besagtes Problem kenne ich nur, wenn ein (oder mehrere) Timer sich selbst "überholt", also das Timerereignis bereits ausgelöst wird, während es noch abgearbeitet wird.

[Uwe Raabe]

Zitat:

Zitat von Delphi.Narium (Beitrag 1429829)

Timer am Anfang des Ereignisses ausschalten und am Ende wieder einschalten.

Klar, aber das löst nicht das Problem, daß dann dauerhaft die CPU (bzw. ein Kern) ausgelastet ist, wenn die Timer-Events quasi im Dauerfeuer triggern. Da muss man sich dann schon fragen, ob so kurze Intervalle überhaupt nötig sind, wenn sie dann eh nicht eingehalten werden können.

[Delphi.Narium]

Timerintervalle sind bei mir eher im Sekunden- oder Minutenbereich, 'nen Timer alle paar Millisekunden auslösen ist eher 'ner Ausnahme. Allenfalls zur Pegelabfrage bei der Bass.dll, um "irgendwas flackern zu lassen" ;-) Aber kürzer als 20 ms macht ein System unbrauchbar.

[Rollo62]

Ja sicher, ich denke hierbei an Intervalle so um die >= 200ms.
Kürzer geht auch, wird aber auch entsprechend kritischer, da würde ich versuchen andere Lösungen zu finden.

Ich benutze oft einen Master-Timer mit einem "kleinsten gemeinsames Intervall",
welches dann durch einfache Integer-Zähler auch mehrere größere Delay-Intervalle erzeugen kann.
Das schont die Timer-Resourcen, ist aber nicht in allen Fällen anwendbar.
Insbesondere für UI-Timing, aber selbst für exaktes Scheduling im Bereich mehrerer Stunden bis Tage ist das aber normalweise durchaus ausreichend.


Und richtig:
Das Einpacken von OnTimer in FTimer.Enabled := False; .... FTimer.Enabled := True; ist ein Muss um Überläufe zu verhindern.
Es sei denn es kommt auf absolut exakte Perioden an, dann müsste man die OnTimer-Rountine besser vom Intervall entkoppeln.

[dummzeuch]

Zitat:

Zitat von Delphi.Narium (Beitrag 1429837)

Aber kürzer als 20 ms macht ein System unbrauchbar.

Ist nicht das minimale Timer-Interval sowieso nur ca. 40 ms ?

[Uwe Raabe]

Zitat:

Zitat von dummzeuch (Beitrag 1429841)

Ist nicht das minimale Timer-Interval sowieso nur ca. 40 ms ?

Nein, 10 ms (ich glaube seit Windows XP):

Delphi-Quellcode:

USER_TIMER_MINIMUM (0x0000000A)

(aus WinUser.h)