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

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