Wolfgang Ciriack hat geschrieben:Drehe doch die Anzeige um und zeige den neuesten Datensatz immer als ersten an.
JA ... das mache ich beim Umsatz so weil es ja nur einen Datensatz mit der Umsatz-Nummer gibt.
ich habe doch, in jeder Rechnung, mehrere Artikel und deshalb auch die selbe ARTNR in verschiedenen Rechnungen als Position.
Nun will ich ja eine Art UNIQUE (ARTNR) aber eben auch "wie oft" der Artikel zu welchem (Tages) Preis gekauft wurde um den Durchschnitt (Tendenz) anzuzeigen.
wenn ich nur die erste Bildschirmseite anzeige ist es ja wie bei Cl*pper ... und nun kommt die "Liste"
bei Cl*pper musste der User zwar immer die Space-Taste drücken um die nächste(n) Seite(n) anzuzeigen aber da ist der User beschäftigt ...
auch hat es "original" viel länger gedauert weil jede ARTNR "einzeln", per SEEK, zuerst addiert wurden bevor eine Ausgabe erfolgte ...
für grosse Arrays waren 64kb einfach zu wenig
es sieht also nun so aus :
1.) am schnellsten wäre es das Array ohne Anzeige komplett zu erstellen ... aber dann sieht der User "nichts" ausser der Sanduhr
2.) man kann, nach der ersten Seite ( > o::rowCount ), einfach auf ein weiteres o:refresh* verzichten ... aber dann denkt der User das die Applikation "hängt".
2.a) klar ein Progressbar ... damit der User was "sieht" ... aber der Scrollbar bewegt sich ja ...
3.) mit Anzeige wird er deutlich langsamer wobei XbpQuickBrowse beim selben Array schneller ist ( weil er nur in der 1st Zeile anzeigt und nicht scrollt )
3.a) am langsamsten ist es mit ::oQBkunden:goBottom() und ::oQBkunden:refreshAll()
3.b) ein wenig schneller sind ::oQBkunden:down() und ::oQBkunden:refreshCurrent() welches den selben Effekt erzeugen
hm ...
man erweitert es auf ein inkrementelles Browse und schränkt es gleich auf den gewünschten SCOPE ( KDNR + ARTNR ) ein ... und lädt den Rest im Hintergrund ( Thread )