TComboBox mit sehr vielen Einträgen

[photor]

Hallo Forum,

in einem aktuellen Projekt nutze ich eine TComboBox, um aus einen Datensatz aus mehreren auszuwählen und darzustellen. Die Datensätze sind durch eine Nummer gekennzeichnet und bestehen aus verschiedenen zugeordneten Funktionen, die dann in einem TChart zur Veranschaulichung und Prüfung auf Plausibilität dargestellt werden. Sie werden aus diversen Files eingelesen und in einem TObjectDictionary gespeichert; die Nummer ist der Key.

Das funktioniert - für meine Testdaten - sehr gut. Allerdings sind das nur ~ 100 Datensätze. Die lassen sich (noch gerade) bequem mit der TComboBox handlen. Wenn die Datensatznummer bekannt ist, kann man die auch direkt eingeben - ist aber meist nicht so.

Im realen Anwendungsfall sind das aber mal schnell mehrere 10000 oder gar 100000 Einträge. Das wird sehr langwierig, da eine bestimmte Nummer anzusteuern - de facto werden dann also nur immer die ersten paar gecheckt, was nicht Sinn der Sache ist.

Ich suche nun nach einer Strategie, wie ich diese Auswahl des darzustellenden Datensatzes übersichtlicher, ergonomischer implementieren könnte. Mir fehlt da im Moment eine gute, mit Lazarus realisierbare Idee (Aufteilung in verschiedene Teilbereiche wäre meine erste Idee; aber wie am besten).

Vielleicht hat ja hier jemand eine.

Dankbar für Input,
Photor

[af0815]

Wie du schon gesagt hast, eine Vorauswahl ist da immer wichtig, mehr als ein dutzend Einträge überbickt kein Benutzer. Die Teilbereiche hängen von deinem Daten ab. Bei Datum/Uhrzeit kann man das schon mal nach Tag, Woche oder Monat, vorauswählen. Notfalls auch Schicht/Stunde/Zeitbereich. Manchmal lasse ich dem Benutzer gar keine große Wahl und er muss Datum und Schicht auswählen, weil dann die Erfahrung habe, das er unter 50 Einträgen bleibt (ist hier eine natürliche Grenze 8 Stunden x 6 Einträge pro Stunde = 48).

Das Problem ist, man muss sich für was Entscheiden. Der Kunde sagt aber in der Testphase, passt oder welche Einschränkung braucht er wirklich.

[photor]

Hallo af0815,

Danke für die Anregungen.

Wie du schon gesagt hast, eine Vorauswahl ist da immer wichtig, mehr als ein dutzend Einträge überbickt kein Benutzer. Die Teilbereiche hängen von deinem Daten ab. Bei Datum/Uhrzeit kann man das schon mal nach Tag, Woche oder Monat, vorauswählen. Notfalls auch Schicht/Stunde/Zeitbereich.

Leider nicht so einfach. Beim Key handelt es sich um Knotennummern (Ergebnisse FE-Rechnung) und bei den Daten um Spannungen (mit denen dann recht komplexe Berechnungen angestellt werden). Die sind zunächst (wenn man nichts weiß) "gleichberechtigt". Nach der Berechnung weiß man, welche relevante Ergebnisse liefern --> das könnte man als Kriterium für eine zweite Rechnung nehmen (wenn z.B. nur kleine Änderungen ...).

Ich habe schon überlegt, die Spannungswerte "vor zu analysieren", habe aber kein gutes Kriterium (dabei wird mir hier kaum jemand helfen können; ist wildes Zeug und hochgradig nicht-linear, Spannungsdifferenzen schweben mir vor ...).

Manchmal lasse ich dem Benutzer gar keine große Wahl und er muss Datum und Schicht auswählen, weil dann die Erfahrung habe, das er unter 50 Einträgen bleibt (ist hier eine natürliche Grenze 8 Stunden x 6 Einträge pro Stunde = 48).

Das Problem ist, man muss sich für was Entscheiden. Der Kunde sagt aber in der Testphase, passt oder welche Einschränkung braucht er wirklich.

Kunde bin ich selbst bzw die Kollegen, die das Tool auch nutzen wollen/sollen. Das Testprojekt werde ich den Kollegen zeigen und Feedback einholen. Vielleicht kommt da ja ein Ansatz.

Eine Idee: die Nummern des Keys sinnvoll in Teilbereiche zerlegen und eine (oder auch mehrere) weitere ComboBoxen, die jeweils nur den Teilbereich anzeigen. Ist aber auch nicht viel übersichtlicher - lässt sich aber vielleicht leichter handhaben (jede ComboBox mit 100 Einträgen --> bei zweien sind das dann schon 10000 Keys - aber ...).

Ich dachte ja, dass es vielleicht noch was anderes als ComboBoxen gibt und ich übersehe das bloß. Wäre gut gut, das wenigstens vorher mal anzuspielen.

Ciao,
Photor

[af0815]

Du gibst selbst bereits die Antwort - erst nach der Berechnung siehst du was relevant ist. Ist nicht schön, aber wenn es sonst keine Auswahl gibt, ist es ein Kriterium.

Ev. Mal einen Kollegen fragen was er nehmen würde, wenn er 1000 Einträge auf 50 reduzieren müsste. Manchmal ist die eigene Sichtweise durch den Tellerrand eingeschränkt.

KomboBox ist ja nur ein Mittel, StringGrid, Memo, Chart,... Und andere. Es ist egal was du nimmst, solange es funktioniert.

[Michl]

Vielleicht gänge auch sowas wie ein Suchfenster (wie bei einem Browser). Man gibt etwas ein, unten öffnet sich eine Vorauswahl (z.B. 20 Elemente), die sich variabel entsprechend der Eingabe anpasst.
Ich nutze seit langem ein "SuggestEdit", was das bewerkstelligt (hatte ich hier mal gepostet viewtopic.php?p=94460#p94460).
Zu finden auch bei SVN https://svn.code.sf.net/p/michlpackages ... lcontrols/
Nur als Idee.

[Sieben]

Wenn eine Zerlegung in Teilbereiche möglich ist, wären auch synchronisierte (DB)Grids denkbar, synchronisiert in dem Sinne, dass die Einträge im zweiten Grid von dem im ersten gewählten Datensatz abhängen und sich beim Blättern oder Scrollen jeweils aktualisieren. Vorteil gegenüber ComboBoxen wäre vor allem die prompte Rückmeldung, ohne die abhängigen ComboBoxen erst wieder neu öffnen zu müssen. Notfalls ergänzt noch um eine dritte oder vierte Ebene.

[kralle]

Gehört nicht jeder Knoten zu einer Masche und gibt es darüber nicht noch weitere Gruppierungen?
Vielleicht sind diese Informationen noch nicht in dem Datensätzen, würden aber vielleicht in Zukunft einiges erleichtern?

Wenn ich an Energieversoger denke, dann habe ich Bundesland, Landkreis, Stadt, Stadtteil, Straße, Hausnummer

Gruß Heiko

[Zvoni]

Ich hätte wieder bei Adam und Eva angefangen.

Du hast Datensätze, welche durch eine Nummer (=Key) gekennzeichnet sind (Alles andere ist irrelevant)

Dabei ist es EGAL, ob es jetzt 100, 10000 oder 100000 Sätze sind.
Die wichtige Frage ist: Was ist das menschl. Entscheidungskriterium, Satz 476 auszuwählen, und eben nicht Satz 9367?
Wenn du hier eine Antwort findest, dann hast du zu 90% dein Eingrenzungskriterium.

Ob du jetzt ein Grid, eine Combobox, die Sockenschublade oder einen Umzugskarton benutzt ist dabei irrelevant

EDIT: Ich hab mir gerade die Wikipedia-Seite für FE-Rechnung durchgelesen (Finite Elemente?)
Du hast gesagt, die Sätze (=Key) sind das ERGEBNIS einer FE-Rechnung.
Wenn ich die FE-Methode richtig verstanden habe, stammen aber diese Finiten Elemente aus einem "übergeordnetem" Objekt, welches eben in diese "kleineren" Elemente aufgeteilt wurde.
Hast du die Info in den Datensätzen, ZU WEM die Keys gehören?

[photor]

Du gibst selbst bereits die Antwort - erst nach der Berechnung siehst du was relevant ist. Ist nicht schön, aber wenn es sonst keine Auswahl gibt, ist es ein Kriterium.

Der Gedanke wäre, vor der Rechnung stichprobenartig zu checken, ob die Daten plausibel sind. Bei einer langen Liste würde man immer die ersten ansehen - mag ja aber als Plausibilitätstest reichen.

Nach einer Rechnung kann ich dann ja sortieren (das tut auch schon).

Ev. Mal einen Kollegen fragen was er nehmen würde, wenn er 1000 Einträge auf 50 reduzieren müsste. Manchmal ist die eigene Sichtweise durch den Tellerrand eingeschränkt.

Ja. Darauf läuft es hinaus: Anwender (bin ich auch) fragen, was die für sinnvoll halten - vielleicht kommt ja auch: "wir rechnen doch sowieso alle Daten durch. Wieso reinschauen?". Dann kann ich mir das schenken.

KomboBox ist ja nur ein Mittel, StringGrid, Memo, Chart,... Und andere. Es ist egal was du nimmst, solange es funktioniert.

Die ausgewählten Daten visualisiere ich ja mittels TChart (um zu prüfen, ob die Ausgangsdaten plausibel sind). Diese werden nach dem einlesen auch schon in ein StringGrid gepackt und farbig gelistet, um sich nicht total in der Zahlenwüste zu verlaufen.

Ciao,
Photor

[photor]

Gehört nicht jeder Knoten zu einer Masche und gibt es darüber nicht noch weitere Gruppierungen?
Vielleicht sind diese Informationen noch nicht in dem Datensätzen, würden aber vielleicht in Zukunft einiges erleichtern?

Wenn ich an Energieversoger denke, dann habe ich Bundesland, Landkreis, Stadt, Stadtteil, Straße, Hausnummer

Die Daten bestehen aus Ergebnissen verschiedener FE (= Finite Elemente) Rechnung. Das FE-Modell besteht zwar aus strukturierten Netzen: Elemente und Knoten, die miteinander verbunden sind. Die Ergebnisse der FE-Rechnung sind den Knoten (oder Elementen) zugeordnet.

Es werden numerische Werte aus den ganzen Ergebnissen extrahiert, um sie weiter zu verarbeiten (Post Processing) wozu sie in Files geschrieben werden. Jedes File besteht aus eine Liste aus Knotennummer und Ergebniswert, die alle zusammengeführt werden. Im vorliegenden Fall sind das 66 Files mit je einer Knotennummer mit zugeordnetem Ergebniswert.

Eine großartige Hierarchie gibt es da leider erstmal nicht: es werden Knoten aus gewählt , die in dem Bereich liegen, der interessiert (das macht man am besten vorher, weil man sie dann in ein Set packen und leichter selektieren kann). Davon werden die Werte aus allen Ergebnisfies extrahiert.

Ich hätte wieder bei Adam und Eva angefangen.

Du hast Datensätze, welche durch eine Nummer (=Key) gekennzeichnet sind (Alles andere ist irrelevant)

Dabei ist es EGAL, ob es jetzt 100, 10000 oder 100000 Sätze sind.
Die wichtige Frage ist: Was ist das menschl. Entscheidungskriterium, Satz 476 auszuwählen, und eben nicht Satz 9367?
Wenn du hier eine Antwort findest, dann hast du zu 90% dein Eingrenzungskriterium.

Ob du jetzt ein Grid, eine Combobox, die Sockenschublade oder einen Umzugskarton benutzt ist dabei irrelevant

Richtig. Für die Daten selbst und das Ergebnis am Ende schon. Aber wenn so ein Ingenieur seine Daten vorher begutachten und einschätzen will ... Eventuell sind ja die Ausgangsdaten schon schlecht. Dann braucht man die Rechnung nicht starten und man erhält eventuell Hinweise, was schief gegangen ist (das ist die Hauptarbeit eines Berechnungsingenieurs ).

EDIT: Ich hab mir gerade die Wikipedia-Seite für FE-Rechnung durchgelesen (Finite Elemente?)
Du hast gesagt, die Sätze (=Key) sind das ERGEBNIS einer FE-Rechnung.
Wenn ich die FE-Methode richtig verstanden habe, stammen aber diese Finiten Elemente aus einem "übergeordnetem" Objekt, welches eben in diese "kleineren" Elemente aufgeteilt wurde.
Hast du die Info in den Datensätzen, ZU WEM die Keys gehören?

Nee, nicht ganz (zum Verfahren siehe auch oben).

Als Key (für das Directory zum Handling im Programm) habe ich die Knotennummern genommen (die gibt den Ort an, für welchen die Daten = Ergebnisse der FE-Rechnung vorliegen, und fasst alle Daten dazu zusammen). Diese sind aber nur der Input für meine eigentliche Rechnung - also noch nicht mein Ergebnis. (Also ist die Struktur den FE-Netzes hier nicht mehr relevant; FE ist an der Stelle beendet[*] und das Post Processing beginnt).

Das Ergebnis (für jeden Knoten) wird aus all diesen Eingaben (für den jeweiligen Knoten) berechnet. Letztendlich wird für jeden Knoten eine Rechnung durchgeführt, die aus einer großen Zahl an Eingabedaten in dem Fall eine einzige Zahl generiert (in dem Fall eine "Schädigung").
Wenn das schließlich vorliegt, weiß ich natürlich, welche Knoten wichtig sind (und z.B. zu hohe oder noch ausreichende Ergebnisse zeigen) und welche nicht.

Fazit:
Wenn ich all die Postings bis hierher zusammenfasse, dann ist eine Vorauswahl schwierig, vielleicht gar nicht nötig oder gewollt (außer, dass ich wissen möchte, was da rein geht) und dann auch noch sehr schwer realisierbar und schon gar nicht ergonomisch und einfach zu handeln.

Ich sage auf jeden Fall "Danke" für die Anregungen. (vielleicht ist die Idee mit der Suchfunktion, die auch genannt wurde, keine so schlechte Anregung; man kann dann vielleicht bestimmte Knoten anfahren).

Ciao,
Photor


[*] die Struktur des FE-Netzes bzw. die Geometrie der zu untersuchenden Komponente ist natürlich relevant für die Auswahl der Knoten für das Post-Processing.

PS: Sorry, das ist jetzt sehr lang geworden. Ich hoffe, das ist OK. Aber das Thema ist komplex.