Verzögerte Suche Vor- und Nachteile

[Bünni]

Wie in meinem anderen Thema beschrieben, habe ich eine verzögerte Suche für eine VirtualStringTree umgesetzt.
https://www.delphipraxis.net/200296-...ml#post1429750

Bei Eingabe in ein Editfeld, wird die Suchfunktionn aufgerufen und filtert alle Knoten entsprechend der Sucheinstellungen und des Suchbegriffs.

Sofortige Suche:
+ der Filter wird bei jedem Tastendruck / EditChange aufgerufen
+ das gefilterte Ergebnis ist sofort nach jedem Tastendruck sichtbar
+ schnell implementiert
- bei sehr langsamen Laptops kann es zu Problemen kommen, da mehr Rechenleistung benötigt wird (beispielsweise Acer Laptops des unteren Preissegments wo das Laden des IE / Edge / Chrome / FF schon 2 Minuten dauert)

Verzögerte Suche:
zu Grunde liegt hier ein TTimer mit 500ms Intervall. Beim EditChange und EditKeyPress wird der Timer aus- und wieder eingeschaltet.
Im Timerevent selber wird der Timer an erster Stelle ausgeschaltet und anschließend die Filterfunktion aufgerufen.
Tippt man mit moderater Geschwindigkeit, wird die Suche solange nicht ausgeführt, bis die Eingabe vollendet ist.

+ weniger Rechenleistung benötigt, auch für langsame Computer geeignet
- das Ergebnis ist erst nach Ende der Eingabe sichtbar bzw. nach einer Eingabepause, die länger dauert als das Timer-Intervall
- ein wenig mehr Aufwand für den Entwickler


Was bevorzugt ihr als Entwickler oder Endanweder einer Software?
Ich bitte um eine sachliche Diskussion in Anbetracht dessen, dass es tatsächlich noch Nutzer von alten und oder sehr langsamen Geräten gibt, die nicht einmal für das Surfen richtig geeignet sind.

[Uwe Raabe]

Da die verzögerte Suche offenbar nur für diese leistungsschwachen Systeme sinnvoll ist, würde ich die Mehrheit mit schnellen Systemen hier möglichst nicht in Mithaftung nehmen. Ich finde es immer wieder frustrierend, wenn ich mit einem gut ausgestatteten System bei meiner Arbeit dann doch wieder auf die Benutzer deutlich langsamerer Systeme Rücksicht nehmen muss.

Mach es doch einfach optional - entweder über eine Einstellung oder über eine Analyse der Systemgeschwindigkeit. Der Aufwand sollte bei einer einigermaßen brauchbaren Struktur relativ gering sein.

Unter wirtschaftlichen Gesichtspunkten sollte man aber eventuell eine Kosten/Nutzen-Analyse voranstellen, ob es überhaupt was bringt, wenn man die Benutzer schwacher Systeme hier pampert.

[Luckie]

Also ich würde eine einfache "Suchen"-Schaltfläche nehmen gekoppelt mit der Return-Taste. Da kann der Benutzer die Suche auslösen wann er will. Und für den Programmierer fällt viel Programmierarbeit weg, die dann doch nie 100 prozentig für alle zufriedenstellend ist.

[Delphi.Narium]

Im Ereignis OnKeyUp auf Taste Return (#13) abfragen. Wird die gedrückt, wird die Suche gestartet.

Mich persönlich stört es kolossal (egal ob schnelles oder langsames System) wenn bei einer Eingabe ein System schonmal anfängt zu suchen, was ich denn eventuell unter Umständen vielleicht suchen könnte, bevor ich überhaupt habe eingeben können, wonach ich suche.

Abgesehen davon fängt so 'ne automatische Suche ja auch schon an zu suchen, wenn ich mal 'nen Schreibfehler mache. Erste Suche bei falschem Zeichen, zweite Suche beim Backspacedruck, dritte Suche beim (hoffentlich) richtigen Zeichen.

Wieviele Suchvorgänge werden gestartet, wenn ich bereits 20 Zeichen eingegeben habe und dann merke, dass das dritte Zeichen falsch ist und ich dann mit den Cursortasten zu dem Zeichen gehe, das korrekte Zeichen eingebe und anschließend das falsche entferne, dann mit der Ende Taste ans Ende der Eingabe gehe, um dann weitere Zeichen einzugeben?

Wenn schon 'ne automatische Suchen, dann auch 'ne Konfiguration in der der Anwender sie abwählen kann und eine Möglichkeit selbst zu bestimmen, nach welcher Zeitspanne dieser Automatismus "zuschlagen" soll.

Prinzipiell hat Luckie mit seinem Einwand 100% recht.

[jfheins]

Ich würde die Suche in einen eigenen Task auslagern und beim Tastendruck einen ggf. laufenden Task abbrechen und den Neuen starten.
Einen Datenbestand zu durchsuchen ist ja nun nichts, was unbedingt im UI Thread stattfinden muss, oder?

Solange die Suche nicht den UI Thread behindert, sehe ich eigentlich nichts was gegen eine automatische Suche spricht.

[Uwe Raabe]

Ich kann jetzt ad hoc nicht absehen ob das immer so ist, aber ist nicht die Suche bei jedem neuen Buchstaben (das Backspace-Problem mal außen vor) eine Verfeinerung der vorherigen Suche? Dann ergibt es vielleicht durchaus schon Sinn die Suche nach dem ersten Tastendruck zu starten und den zweiten dann auf das Ergebnis los zu lassen. Könnte durchaus von Vorteil sein, auch wenn das erste Suchergebnis gar nicht mehr zur Anzeige kommt, sondern gleich das der verfeinerten Suche. Das ist dann aber vermutlich nur praktikabel mit einem separaten Such-Thread.

[Bünni]

Zitat:

Zitat von jfheins (Beitrag 1429761)

Ich würde die Suche in einen eigenen Task auslagern und beim Tastendruck einen ggf. laufenden Task abbrechen und den Neuen starten.
Einen Datenbestand zu durchsuchen ist ja nun nichts, was unbedingt im UI Thread stattfinden muss, oder?

Solange die Suche nicht den UI Thread behindert, sehe ich eigentlich nichts was gegen eine automatische Suche spricht.

Ich synchronisere mit dem Hauptthread. Das Ergebnis muss ja irgendwie auf den Bildschirm. Bei meinem Beispiel kann man den Thread auch weglassen.

[Delphi.Narium]

Wenn ich weiß, was ich suche, warum müssen dann zwischendurch auf biegen und brechen Suchen durchgeführt werden, wenn ich als Anwender sowieso nur das Ergebnis der letzten Suche benötige?

Ich kann nunmal nicht so aberwitzig schnell schreiben und Buchstabendreher sind der Normalfall.

Oder fragen wir mal so:

Ist hier im konkreten Fall die sofortige Suche eine Anforderung der Anwender oder nur ein (überspitzt formulier) "Ich kann das programmieren, also mach' ich 's auch"?

Käme nie auf die Idee sowas zu implementieren, wenn es nicht eine explizite Anforderung seitens der Anwender ist. Auch dann nicht, wenn ich 's mit knapp 'nem Dutzend Quelltextzeilen realisiert bekomme.

[joachimd]

Ich habe auch bei schnelleren Systemen immer die Suche über Timer ausgelöst. Jeder Tastendruck zieht den Timer auf und im Timer-Event wird gesucht (nach Timer.Enabled auf false). Wenn der Timer auf wenigen ms steht (100, 200) verzögert es auch einen Schnelltipper nicht unbedingt. Das ist immer noch schneller, als dass die Augen den Inhalt der gefilterten Liste am Bildschirm erfassen können.

[old7]

Ab dem dritten Zeichen im TEdit kann von mir aus die Suche losrödeln, vorher Bitte nicht vor einem Return im TEdit.

Kommt mMn aber immer darauf an, wieviele Datensätze (wie und wo) durchsucht werden sollen.

Optinonal umschaltbar bevorzuge ich (ab dem 3. Zeichen oder erst ab Return).