In einer Scrollbox erstelle ich eine große Anzahl von TControls.
In meinem Test brauchen 1000 TEdits ca. 34 Sekunden; sehr lahm ...
schalte ich visible:=false während der Erstellung, so sind es immer noch 17 Sekunden.
Wie kriege ich da noch mehr Dampf rein?


Selbst die Clear Methode braucht bei 1000 Einträgen: 8,5s bei Visible:=True, ca. 5 Sekunden bei Visible:=false

Hallo,

DisableAutoRange und EnableAutoScroll?

1000 Edits sind doch eh nicht sichtbar, erstell 100 oder so und verändere sie entsprechend den Erfordernissen.

Das werde ich mal testen und hier berichten.
Stimmt, die 1000 TEdits sind nicht sichtbar, aber führen trotzdem zu sichtbaren Updates in der sichtbaren Komponenten und flackernder Anzeige.

Welchen Anwender möchtest Du denn 100 oder gar 1000 Edit-Felder zu muten
Egal, was das Programm macht, wie gut es auch sein, ich würde es sofort per Entfernen in den ... jagen

Naja, eine große Tabelle aus einer DB bzw. ein Grid ist auch nicht viel kleiner
Naja, 100 tritt selten auf, 1000 so gut wie nie.
Es handelt sich um eine Warenwirtschaftsanwendung, welche z.B. Lieferscheine, Komissionslisten, Rechnungen etc. erfasst.
Und dort bestehen die einzelnen Zeilen schon aus mehreren Edit Feldern
(z.B. Artikelname, Art.Nr., Lagerort, Menge, Einheit, Einzelpreis, Rabatt, Gesamtpreis (Readonly), MwSt.Satz). Diese Felder müssen nicht alle eingetippt werden; je nach Art der Position (nur Text, Text und nur Gesamtpreis; Artikel direkt aus der Lagerverwaltung) muss eventuell bei der Erfassung gar nichts getippt werden (Barcodelesegerät in der Schnellerfassung).

Ein solcher Beleg liegt meist zwischen 2 bis 10 Zeilen.
Aber durch einen Sammelrechnungslauf können auch n-Belege zu einer Rechnung zusammengestellt werden, so dass dann eine max. ca. 8 seitige Rechnung rauskommt. Bei ca. 50 nutzbaren Zeilen pro Rechnungsseite ist man da schnell bei etwa 400 Zeilen á 1 bis 9 Editfelder -> im worst case also etwas über 3000 Editfelder möglich.

Ich komme ganz gut voran und die TScrollbox macht sich nicht schlecht dabei ....

Und warum nimmst du nicht einfach ein TStringGrid??? Handhabt sich viel einfacher, verbraucht 1000-mal weniger Ressourcen, ist nur eine Komponente statt 1001 und geht viel, viel schnell!

Warum so?

Weil das Grid leider nicht die Möglichkeit bietet:
*variable Zellenanzahl pro Zeile (nur ganze Spalten lassen sich abschalten/unsichtbar machen)
*variable Breite pro Zelle muss möglich sein (geht in Grids auch nur Spaltenweise)
Das Mergen von Zellen hilft hier leider nicht.
*in einigen Fällen mehrere Eingabeelemente untereinander bzw. nebeneinander in einer Zelle (das hier ginge eingeschränkt z.B. mit TAdvStringGrid)

Ich habe mir etliche Gridvarianten (auch kommerzielle) gesucht und wäre am liebsten mit dem TAdvStringGrid vom TMSSoftware gestartet; aber die beiden obigen Aspekte kann das Grid leider nicht abdecken.
Hinzu kommt, das die einzelnen Felder gerne speziell behandelt werden wollen (z.B. bereits beim Eingeben Grossbuchstaben, Aufbereitung von Zahlen, Prozentangaben, führende Leerzeichen abschneiden, spezielle Cursorbehandlungen, Speedbuttons für Suchfunktionen, Lookups in externe Tabellen, Richview-Komponente für RichText Eingaben mit variabler Feldhöhe etc.).
Da hierfür bereits eine Reihe von TEdit-Ableger existieren, wäre aus meiner Sicht ein erheblicher Aufwand beim Grid einerseits eingespart worden (einfachere/schnellere Speicherverwaltung), andererseits aber durch die mühsamere Integration der bestehenden TEdits in das Grid wieder verloren gegangen.
So läuft das eigentlich relativ gut. Eine Ableitung der TScrollBox war in zwei Stunden fertig und getestet.
Für jedes der verschiedenen Eingabe-Optionen habe ich ein Frame erstellt, welches die notwendigen speziellen TEdit-Felder enthält.
Das ist ratz-fatz erledigt gewesen und die Funktionalität sieht echt aus wie gewünscht.
Nur ein wenig Tuning beim Anlegen (bzw. laden der Elemente aus einer DB) wäre noch nötig. Der Zugriff und das Scrolling auf die Elemente sind schnell wie der Wind.
Aber bis zu 50 Zeilen ist fast keine Verzögerung zu spüren erst danach scheint die Verwaltung überproportional mehr Zeit zu verschlingen. Aber da 98% aller Dokumente in der Bearbeitung kleiner 20 Zeilen sind, kann man damit bestimmt gut leben.

Hm, ok. Und einfach eine Datenbank nehmen geht auch nicht? Du könnest doch einfach nur eine Zeile einrichten, und dann zwischen den verschiedenen Datensätzen durchschalten...
Nur so als Vorschlag, weil das müsste doch gehen, um so viele Komponenten zu vermeiden (was ja automatisch einen hohem Performanceverlust bedeutet).

Ein Performance-Tip: Lass das Align auf alNone und berechne die Positionen selbst. Jede Zuweisung auf Align für ein Control sorgt dafür, dass alle Controls im Container neu aligned werden. Der er dafür alle Controls durchläuft, ist die Laufzeit dadurch schon mal quadratisch zur Anzahl der Controls. Das gleiche gilt auch für Clear, wo bei für jedes Control, das entfernt wird, alle anderen Controls repositioniert werden.

Edit: ich habe gerade gesehen, TWinControl hat die Methoden DisableAlign und EnableAlign. Damit kannst du bei vielen Änderungen an Controls das Neuausrichten temporär abschalten.

Stefan

Ich hab jetzt zwar keine Tipps für dich aber falls du ein wenig Geld investieren willst.. gibt es da ein Grid was einiges abdeckt was du brauchst..

www.devexpress.com/

Das DevExpress Grid benutze ich jetzt schon seit langem und es gibt bei diesem Grid wirklich nur wenige Dinge die man nicht machen kann.. und wenn dann Mail an Support und n Tag später hat man die Lösung ist ne feine Sache.

Eine Demoversion von diesem Grid ist ebenfalls auf dieser Seite zu finden. So ersparst du dir 3000 Edits und hast ein Grid mit verschiedenen Ansichten und und und... überlegs dir..

Hier der Direktlink auf das Express Quantum Grid für D6:

www.devexpress.com/P...s/VCL/ExQuantumGrid/

@Alias5000:
Die Daten direkt in der Tabelle zu bearbeiten erzwingt eine Reihe von zusätzlichen Zwischenspeicherunge z.B. bei Bestandsänderung im Lager (alte gebuchte Menge merken, neue Sollmenge merken, erst wenn der Gesamtbeleg gespeichert wird, dann alle Differzbuchungen im Lager durchführen). Außerdem muss alles in eine Transaktion gelegt werden, die, wenn die Anwender die Editierung lange stehen lassen, sehr lange läuft und andere Stationen behindern kann.
Außerdem gibt's dann richtig Probleme, wenn der Anwender nach etlichen Änderungen, löschen, neu einfügen von Zeilen den gesamten Beleg mittels cancel verwirft. Da darf dann in der Transaktions- und Buchungsverfolgung nix schief gehen.
Ein Arbeiten "live" auf der Tabelle haben wir erwogen, getestet und dann verworfen. Die Editierung machen wir jetzt lieber "offline", also Beleginhalt in das Grid/Scrollbox laden, Benutzer editiert so lange er will; Cancel -> fertig, Save -> Belegdaten speichern und Differenz-Buchungen bzw. Neubuchungen ausführen

@Stefan,
guter Hinweise mit dem Seiteneffekt der Align Property. Die macht mir die Berechnung der Top-Koordinate sehr einfach, aber wenn das diese Seiteneffekt hat, kann ich das auch selbst mit wenigen Zeilen schnell selbst erledigen. Werde ich mal überprüfen.

@Alpha_Wolf:
ich hatte mir die Grid von devexpress auch angesehen (die sind ja bekannt für Ihre vielfältigen Grids), habe es aber verworfen (kann mich momentan nicht erinnern warum). Das QuantumGrid DBaware oder Standalone, könnte in Frage kommen.
Da Du die Komponente ja kennst, unterstützt das QuantumGrid
*dynamische Zellenanzahl pro Zeile (z.B. Zeile 1: 5 Zellen, Zeile 2: 3 Zellen, Zeile 3: 9 Zellen)
*dynamische Zellenbreite individuell pro Zeile (z.B. Zeile 1: 40, 100,50,50,20 Pkt., Zeile 2: 250, 20 und 100Pkt, Zeile 3: 20, 250,30,30,30,100, ... Pkt)?
*Funktionieren nur die default-Editoren der Suite oder lassen sich eigene Tcontrol/TEdit Abkömmlinge einfach als Editoren verwenden

Vielen Dank

So. hier noch mal der letzte Stand des "tunings".
Alle Tests für die Erzeugung von 1000 TEdit-Komponenten:
Ursprüngliche Version (align:=alTop) 34 Sekunden
dito mit visible:=false 17 Sekunden

Nach dem Tip bezüglich des align (jetzt wieder auf Default per align:=alnone):
Sichtbar 5 Sekunden
mit visible:=false -> unter 1 Sekunde!!

Na, das ist doch mal was ...

Gibt's doch noch eine Möglichkeit das Updaten der Scroll box ausser durch visible:=false zu unterbinden, während ich umfangreiche Operationen daran durchführe (z.B. Clear, oder jetzt manuelle TOP updates, wenn mitten Drin ein Objekt eingefügt oder gelöscht wird)?
Immer Visible:=False und wieder True zu schalten, lässt die Anzeige unschön flackern und aussehen. Dafür brauche ich noch eine etwas "hübschere" Lösung.

auch auf die Gefahr hin ...

nimm max. 10 sichtbare Editzeilen (Edit1..Edit9) und verwalte den Rest über eine Scrollbar!

@Kroko,
habe ich nicht ganz verstanden.
Scrollbar ist doch nur die Laufleiste, meinst Du Scrollbox (so wie ich es jetzt schon tue)?

Also mein Ansatz funktioniert jetzt einwandfrei, die Ladezeiten könnten etwas besser sein, aber da spielt auch der Zugriff auf die mehrfache Master-Detail Tabelle eine Rolle, wie ich eben mit dem SQL Monitor gesehen habe.
Editieren, Speicherverbrauch etc. der jetzigen Lösung scheinen problemlos.

nein, scrollbar war schon richtig

angenommmen Du hast 40 Edit-Zeilen â 9 Editfelder, dann würde ich 10 Zeilen (max) erzeugen und anzeigen. in einer scrollbar würd ich min=0 max =40 setzen und position gebe den obersten Zeilenindex an! ein bißchen Arbeit aber keine 4000 Edit-Felder!

Alles klar, so war das gemeint.
Stimmt, das wäre auch eine Lösung. Ich müsste mir eine Datenstruktur anlegen (z.B. TObjectList), in der ich alle Zeilen speichere und nur für die Anzeige dann jeweils die nötigen Daten aus dem TObject in die angezeigten TEdits kopieren.
Wäre durchaus möglich.
Ich würde das noch etwas variieren, da ich ja unterschiedliche Zeilentypen mit unterschiedlichen Controls und sogar unterschiedlicher Höhe habe.
Man könnte also (ähnlich meinem jetzigen Entwurf) pro Zeilentyp einen Frame definieren und den dann jeweils für die Anzeige erzeugen. Die Daten müssen dann jeweils zwischen dem der TObjectlist und dem zugehörigen Anzeige-Frame hin- und her kopiert werden.
Der Aufwand liegt dann in der Tat eher bei der Programmierung des Scrollings und Updating der internen Datenstruktur mit den angezeigten Frames (d.h. wie viele Zeilen ab Nr. x passen auf die Anzeige [Anzeige hat feste Höhe, Zeilen je nach Type unterschiedliche Höhen; im Worst case passen z.B. nur 3 Zeilen in die Anzeige, im best case vielleicht 15], alte Frames der Anzeige löschen, neue Erzeugen, Daten aus der internen Datenstruktur in die Anzeige kopieren; bei Datenänderungen diese konsistent aus den Frames wieder in die Datenstruktur zurück kopieren etc.).
Dieses Prinzip wurde in der DOS Applikation verwendet, deren Redesign ich jetzt in Delphi durchführe.
Wenn man aber mal die Anzahl der erzeugten Elemente betrachtet, erzeugt (und vernichtet) man bei diesem Ansatz wesentlich mehr Elemente, als beim Scrollbox Ansatz.
Beispiel:
Dokument enthält 50 Zeilen, Anzeige soll einen Ausschnitt von 10 Zeilen anzeigen; der Einfachheit halber gehen wir hier mal von konstanten 5 TEdits/Zeile aus

Aktueller Ansatz: Alles beim Laden erzeugen -> 250 TEdits werden erzeugt.
rumblättern und navigieren in den TEdits funktioniert ohne weitere Logik des Programmes rein durch Windows; Daten müssen nicht umkopiert werden, weil die TEdits bzw. Frames genau die angezeigten und gespeicherten Daten gleichermaßen repäsentieren.

Krokos Ansatz (wenn ich ihn so richtig verstanden habe):
*Ladevorgang -> alles in die interne Datenstruktur lesen;
die ersten 10 Zeilen anzeigen -> 50 Elemente anlegen
*Focus-änderungen innerhalb der Anzeige -> das macht Windows alleine
*eine Zeile nach unten scrollen -> alle Elemente löschen und neu erzeugen (in diesem Beispiel hinkt das, weil wir von gleichen Zeilen ausgehen, aber in der Realität können die Zeilen unterschiedliches Format und damit unterschiedliche Höhe haben)
-> 50 Elemente löschen und neu zeichnen

Schon wenn man also 5 Zeilen runtergescrollt hat, wurden bereits 300 Elemente erzeugt (und 250 gelöscht). Da hat das Delphi Programm + Windows und die Speicherverwaltung viel zu tun. Eventuell bremst das auch weiter aus, weil (ähnlich wie jetzt im Falle meiner Scrollbox) das Erzeugen/Löschen der Elemente von Windows live angezeigt wird (deshalb greife ich ja noch zum "visible:=false" -> erzeugen -> "visible:=true").

Ich komme relativ flott voran in der Programmierung. Ich werde hier mal eine Hardcopy posten, wenn die Implentierung der unterschiedlichen Höhen/Feldanzahl/Breite abgeschlossen ist. Die momentan funktionierenden Abschnitte haben immer noch den gleichen Typ und sehen deshalb noch streng tabellarisch aus.
Nächste Woche bin ich aber im Urlaub (juchu!) also kann es noch 14 Tage dauern.

Hast du eigentlich eine Lösung für das Problem gefunden, dass die Anzeige durch das Schalten von Visible immer flackert? Das würde mich auch mal interessieren.

Zu dem alternativen Ansatz, nur die Elemente zu erzeugen, die gerade sichtbar sind: so extrem muss das mit dem erzeugen und Löschen der Elemente nicht sein. Wenn du im eine Zeile scrollst, brauchst du ja nicht alle Elemente freigeben und neu anlegen - es würde ja reichen, nur die Elemente der neu sichtbaren Zeile zu erzeugen, die der nicht mehr sichtbaren Zeile der vernichten und alle anderen um eine Zeile zu bewegen.

Stefan

Stefan,
nein, das habe ich noch nicht. Da ich das nur beim Ladevorgang mache, ist das erst mal unkritisch. Das packe ich in die späteren Optimierungen rein. Ich muss mit der Gesamtapplikation sehen, das ich den Terminplan halten kann.

Wegen der Verschiebung ohne jedesmal neu zuzeichnen:
Das hatte ich mir auch überlegt, Beim Scrollen nach oben oder unten muss man ja prüfen, wie viel Platz die neue Zeile braucht (nennen wir das hier mal "Diff"). Dann muss man bestimmen wieviele "alte" Zeilen dann rausgeworfen werden müssen. Diese alten Zeilen dann löschen, alle dann noch bestehenden Controls um dem Diff Betrag verschieben und dann die neue Zeile oben bzw. unten erzeugen. Aber der Aufwand die Daten zwischen der internen Datenstruktur und der Anzeige immer zu syncronisieren ist auch nicht ohne.

Insgeheim lohnt sich das aus meiner Sicht nicht, die Scrollbox macht Ihre Arbeit schon sehr gut. Da lohnt sich nicht mal auf eine Gridkomponente umzustellen, wenn man eine findet, welche den Anforderungen genügt.

motion hat folgendes geschrieben:

Schon wenn man also 5 Zeilen runtergescrollt hat, wurden bereits 300 Elemente erzeugt (und 250 gelöscht). Da hat das Delphi Programm + Windows und die Speicherverwaltung viel zu tun. Eventuell bremst das auch weiter aus, weil (ähnlich wie jetzt im Falle meiner Scrollbox) das Erzeugen/Löschen der Elemente von Windows live angezeigt wird (deshalb greife ich ja noch zum "visible:=false" -> erzeugen -> "visible:=true").

Quatsch, es bleiben die 50 erzeugte EditFelder, die nur neu gefüllt werden müssen!

TopIndex=Zeile8 -> Edit1= Daten[8,1] Edit Daten[8,2] etc!