Hallo zusammen,
ich bin gerade dabei ein kleines Progrämmchen zu basteln, dass mir aus Text-Dateien einen String heraussuchen und die betreffende Zeile sowie die X folgenden in eine neue Datei kopieren soll.
Zuerst hab ich das Programm ohne Threading geschrieben und das hat auch soweit funktioniert. Nur blockiert verständlicherweise die GUI, da die Dateien teilweise 2 Millionen (ja, 2 Millionen) Zeilen haben. (Im Prinzip ein "Log-File-Analysator", in dem dann nach Verbindungsabbrüchen gesucht wird.)
Jetzt möchte ich aber ein ProgressBar einbauen, da die Bearbeitung doch recht lange dauern kann - abhängig davon wie oft der Suchstring gefunden wurde.
Mein Problem ist jetzt folgendes:
Die ProgressBar akzeptiert als Grenzwerte nur Int32. Wenn ich nun die Zeichen der Datei über FileInfo auslese, bin ich da locker ausserhalb des Wertebreiches. Um das zu verhindern mache ich derzeit folgendes (nur die meiner Ansicht nach wesentlichen Elemente):
private void Startbutton_Click(object sender, EventArgs e)
{
progressBar1.Maximum = Convert.ToInt32(myInfo.Length/10000);
progressBar1.Minimum = 0;
}
...
void StartReading()
{
if (bearbeiteteZeichen % 10000 == 0)
{
wert = bearbeiteteZeichen / 10000;
this.Invoke(new MethodInvoker(FillProgressBar));
}
}
...
private void FillProgressBar()
{
progressBar1.Value = Convert.ToInt32(wert);
}
Könnt Ihr mir einen Tipp zu einem Lösungsansatz geben, wie ich das Füllen der ProgressBar vernünftig hinbekomme? Der Zeitaufwand für das Auslesen und Kopieren hat sich durch die ganze Rechnerei nämlich ziemlich deutlich erhöht...
Ich selbst habe schon über folgende Dinge nachgedacht:1.Ermittlung, wie lange der Vorgang dauern wird und dann entsprechend die ProgressBar füllen (falls das irgendwie möglich sein sollte, was ich aber bezweifle). 1.Mit Timern arbeiten und alle 100ms den Stand (bearbeitete Zeichen) abfragen und die ProgressBar füllen.
Letztere Variante wäre für mich auch ohne Hilfe zu realisieren. Trotzdem würde ich gerne wissen, wie Ihr vorgehen würdet.
Grüße,
der Michael
Hallo Lumbra,
wenn du nicht weisst wie viele Zeilen du hast wird es sehr schwierig einen Fortschrittsbalken zu erstellen.
Ich würde da einfach eine Ladeanimation und einen Text "Bitte warten" anzeigen, solange der Vorgang läuft.
Diese Rechnerei kostet einfach immer sehr viel Zeit und wenn nicht unbedingt nötig ist es besser darauf zu verzichten.
Oftmal stimmen diese Rechnereien auch nicht genau (siehe Explorer-Zeit beim kopieren)
Gruss
Michael
Hallo Lumbra,
die Verwendung eines Timers hat auf jeden Fall den Vorteil, dass die Berechnung garantiert ausreichend selten durchgeführt werden. Und du machst dich von der konkreten Geschwindigkeit des Rechner unabhängig. Kann man also durchaus so machen.
herbivore
eine andere idee wäre:
wenn es sich tatsächlich um dateiEN handelt, könntest du einfach die dateianzahl in die processbar reinschreiben und beispielsweise mit der dateigröße gewichten.
Ich würde da einfach eine Ladeanimation und einen Text "Bitte warten" anzeigen, solange der Vorgang läuft.
Ich hab mir nochmal die ProgressBar-Klasse angesehen und das "Marquee-Design" für mich entdeckt. Nachdem ich das mal schnell ausprobier habe, ist die Geschwindigkeit um etwa den Faktor 20 höher... Die Rechnerei hab ich aber auch wahrscheinlich etwas "dümmlich" realisiert 😉
die Verwendung eines Timers hat auf jeden Fall den Vorteil, dass die Berechnung garantiert ausreichend selten durchgeführt werden.
Ja, das war auch der Grund weshalb ich darüber nachgedacht habe. Aber im das Problem mit den Ausgangswerten hab ich damit noch nicht so ganz gelöst...
Ausserdem habe ich im Moment damit Probleme, das Timer-Event der Form-Klasse aus dem Thread heraus aufzurufen.
Deshalb bin ich bei den Marquee-Design der Progress-Bar gelandet. Für den Zweck reicht es allemal...
wenn es sich tatsächlich um dateiEN handelt, könntest du einfach die dateianzahl in die processbar reinschreiben und beispielsweise mit der dateigröße gewichten.
Es handelt sich tatsächlich um Dateien, aber die Abarbeitung erfolgt "manuell" nacheinander. Sind ja nicht grad hunderte. So um die 10 werden es maximal mal sein... Aber wenn es mehr werden, dann macht es durchaus Sinn. Dann aber mit doppelter ProgressBar 😉
Grüße,
der Michael
Hallo Lumbra,
[...] mit der dateigröße gewichten.
ist eine sinnvolle Idee. Wenn die Dateien nicht nahezug gleich groß sind, macht eine ProgressBar
, die die Anzahl verarbeiteter Dateien anzeigt, nicht wirklich Sinn.
Dann aber mit doppelter ProgressBar 😉
Auch dann solltest du die Berechnung von der Dateigröße abhängig machen 😉.
m0rius
Edit: Quote-Tags korrigiert.
Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg
Dann aber mit doppelter ProgressBar 😉
Auch dann solltest du die Berechnung von der Dateigröße abhängig machen 😉.
Dann macht es aber auch wirklich Sinn - um den ungefähren Zeitfortschritt einschätzen zu können...
Grüße,
der Michael
Hallo Lumbra,
Dann macht es aber auch wirklich Sinn - um den ungefähren Zeitfortschritt einschätzen zu können...
richtig. Nichts ist nerviger als ProgressBar
s, die anzeigen, man hätte schon 95% der Zeit hinter sich, die dann aber verschweigen, dass es erst 5% der Dateigröße sind 😐.
m0rius
Mein Blog: blog.mariusschulz.com
Hochwertige Malerarbeiten in Magdeburg und Umgebung: M'Decor, Ihr Maler für Magdeburg