Ist es möglich die Größe einer Datei in C# zu ermitteln (Windows Forms)?
Hallo, Ich habe schon einige Beispiele gesehen für C# (Konsolenanwendung) um die Größe eines Verzeichnisses herauszulesen. Leider habe ich nichts gefunden um die Größe eines Verzeichnisses zu lesen in C# (Windows Forms). z.B. das man in ne Textbox den Pfad der Datei eingibt, auf einen Button drückt und die Größe in einer anderen Textbox angezeigt wird.
Ist das überhaubt möglich in Windows Forms? Wenn ja wie? (Tipps)
1 Antwort
Die Frage hat eigentlich kaum etwas mit Windows Forms zu tun.
/* Aus der Textbox auslesen. */
string path = this.textBox1.Text;
/* File IO betreiben. */
System.IO.FileInfo info = new FileInto(path);
long size_in_bytes = info.Length;
/* "Kulturunabhängigen" String draus machen. */
System.IFormatProvider provider = System.Globalization.CultureInfo.InvariantCulture;
string size_str = size_in_bytes.ToString(provider);
/* In die Textbox schreiben. */
this.testBox2.Text = size_str;
Das kannst Du z. B. in einen EventHandler (für OnClick-Event oder so etwas) Deines Buttons tun.
Nur die erste und die letzte Anweisung hat etwas mit Windows Forms zu tun.
Du könntest den Pfad auch von der Console auslesen oder als Kommandozeilenargument entgegennehmen und Du könntest das Ergebnis auch auf die Konsole oder in eine andere Datei herausschreiben. Du brauchst nur einen String mit dem Pfad und am Ende bekommst Du die Dateigröße. Woher der String kommt und wo Du die Größe am Ende "hinpackst", ist für den eigentlichen Code, der die Größe ermittelt, egal.
Grundsätzlich sollte der Großteil Deines Codes nichts mit dem user interface zu tun haben. Hat er das, dann ist die Softwarearchitektur nicht sauber.
Ich empfehle, eigene Klassen zu bauen, welche die eigentliche "Programmlogik" implementieren. Da könnte z. B. auch eine "IO"-Klasse dabei sein, die Dateigrößen ermittelt.
Das user interface "bedient" dann ausschließlich diese Klassen.
Benutzerschnittstellen sollten immer leicht austauschbar sein, weil sie relativ "kurzlebig" sind.
Außerdem.
this.testBox2.Text = size_str;this.textBox2.Text = size_str;Sehr wahrscheinlich heißt die TextBox "textBox2" und nicht "testBox2". ;-)
Ach herrje, wenn man zu schnell tippt. ;-)
Das mit den /* "Kulturunabhängigen" String draus machen. */ habe ich nicht ganz verstanden. wo soll ich das hinpacken
Du kannst alles direkt hintereinander packen.
Die zwei Zeilen (würde auch in einer gehen, wäre aber ein bisschen lang) machen aus dem "long" einen "string" und zwar auf eine Art und Weise, die nicht von der Sprache Deines Betriebssystems abhängt. (Was in 99.9 % aller Fälle das ist, was man möchte.)
Das ist in meinen Augen eine der größten "Macken" in .NET. Standardmäßig arbeiten alle "ToString()" und "Parse...(...)"-Methoden "kulturabhängig", also abhängig von der Sprache und Region des Betriebssystems, auf dem der Code gerade läuft. Wenn man das nicht möchte, muss man explizit eine Überladung verwenden, die einen IFormatProvider entgegennimmt, um das Defaultverhalten zu "überschreiben". Das ist wirklich sehr "unintuitiv".
In Java ist es genau andersherum. Hier wird standardmäßig "kulturneutral" konvertiert und wenn man "kulturabhängig" konvertieren möchte, muss man das explizit hinschreiben. Das finde ich um einiges logischer. Insbesondere Entwickler, die auf englischsprachigen Systemen entwickeln, merken unter Umständen gar nichts von der "kulturabhängigen Konvertierung", weil die "neutrale Kultur" (InvariantCulture) beinahe en-US (amerikanischem Englisch) entspricht (aber auch nicht ganz, die Formatierung mancher Zahlen ist anders und "en-US" hat beispielsweise "Dollar" als Währung, während die InvariantCulture eine "neutrale Währung" namens "Currency" (Währung) hat).
Warum "stört mich das so sehr" bei .NET? Nunja, ich muss als Entwickler explizt etwas zusätzliches hinschreiben, wenn ich eine Funktionalität (kulturabhängige Formatierung) nicht haben möchte, ansonsten wird es einfach gemacht. "Ohne dass ich etwas gesagt habe" sozusagen, geht .NET einfach davon aus, dass ich Strings gemäß der Betriebssystemsprache formatieren oder parsen möchte. In der Regel stimmt das aber nicht. Eigentlich möchte man nur in ganz speziellen Fällen Ein-/Ausgaben gemäß der Betriebssystemsprache formatieren und dann sollte sich der Entwickler meines Erachtens auch im Klaren darüber sein, was er dort tut und es explizit hinschreiben. In Java ist das genau so, in .NET ist es genau anders herum.
Das soll kein "Java ist besser als .NET"-Rant werden. Ich entwickle selbst sehr gerne in C-Sharp. Es ist eine tolle, äußerst ausdrucksstarke Sprache. Obwohl ich Microsoft eigentlich nicht "mag" (bin Linux-User), muss ich sagen, dass hat Microsoft hier viele Dinge eindeutig besser gemacht, als Sun Microsystems bzw. Oracle mit Java. (Viele Entwickler sagen, C-Sharp sei "Java done right".) Aber dass defaultmäßig "kulturabhängig konvertiert" wird, ist einfach ein riesiger Makel. Für mich gibt es überhaupt nichts, was diese Entscheidung rechtfertigen könnte und es gibt mit Sicherheit reihenweise Programme, die schwer zu lokalisierende Programmfehler/Bugs beinhalten und auf manchen Systemen nicht das gewünschte Ergebnis bringen oder einfach komplett versagen, weil dem Entwickler nicht klar war, dass alle "ToString()"/"Parse...(...)"-Vorgänge, sofern er nicht explizit etwas anderes angibt, abhängig von der Betriebssystemsprache erfolgen.
Ok, danke! :) Bei mir funktionierts leider noch immer nicht :/. Zwar keine Fehlermeldung jedoch startet sich der Debugger sobald man auf den Button klickt :/
Ferndiagnose ist immer so schwer.
Du schaffst das schon.
Kommentiere doch erst einmal alle Zeilen aus und dann von oben nach unten eine nach der anderen ein. Dann kannst Du den Fehler sicher eingrenzen.
"Ohne dass ich etwas gesagt habe" sozusagen, geht .NET einfach davon aus, dass ich Strings gemäß der Betriebssystemsprache formatieren oder parsen möchte. In der Regel stimmt das aber nicht." Du denkst aber schon gelegentlich an den Nutzer, oder?! Anderes Beispiel: Die Vorteile von .NET liegen ja auf der Hand. Ich kann meine Desktop-Anwendung ruck-zuck in eine Webapplikation umwandeln. Nach Deiner Logik müssten die Zahlen nun bei jedem Request grundsätzlich in englischem Format erscheinen. Nein, das genau wollen die Kunden eben nicht. Gewöhn dich dran, die Zahlen entsprechend jedes Mal entsprechend dem erwarteten(!) oder angeforderten Format anzubieten. Nutzer der Website aus Deutschland wollen deutsches Format, Engländer entsprechend anderes. Genau so kannst und solltest Du auch Desktop-/Smartphone Apps entwickeln!
Du denkst aber schon gelegentlich an den Nutzer, oder?!
Wenn ich zum Zwecke der Ein-/Ausgabe tatsächlich so formatieren möchte, dann kann ich das ja angeben. ;-)
Ich schreibe häufig Parser oder lese Daten aus einer Datei von einem Socket-Interface ein. Mal ganz ungeachtet dessen, ob und wann man hier ein Binärformat anstatt eines Textformats verwenden sollte (das wäre eine andere Diskussion), brauche ich da ein konsistentes Datenformat.
Die sprachabhängige Formatierung macht nur beim User-Interface Sinn. Und das User-Interface ist normalerweise nicht der größte Teil der Anwendung.
Gewöhn dich dran, die Zahlen entsprechend jedes Mal entsprechend dem erwarteten(!) oder angeforderten Format anzubieten. Nutzer der Website aus Deutschland wollen deutsches Format, Engländer entsprechend anderes. Genau so kannst und solltest Du auch Desktop-/Smartphone Apps entwickeln!
Selbst in diesem Fall macht das alles nur dann Sinn, wenn die gesamte Anwendung lokalisiert ist. Ein Aufwand, der bei kleinen oder hochspezialisierten (z. B. wissenschaftlichen, kleiner Nutzerkreis, alle der englischen Sprache mächtig) Anwendungen häufig nicht sinnvoll ist. An dieser Stelle macht eine Pauschalisierung einfach keinen Sinn.
Wenn ich in eine spezialisierte Anwendung einen Wert eingebe, dann erwarte ich, dass sie sich konsistent verhält (und dass dieses Verhalten spezifiziert ist) und nicht, dass sie sich nach meinem Standort oder nach meiner Betriebssystemsprache verhält. Dein C-Compiler erwartet auch einen "." wenn Du einen "float" oder "double" angibst und nicht etwa plötzlich ein "," nur wenn Du auf einem deutschsprachigen System bist.
So, habe es nun teilweise geschafft.
Leider kann man nur die größe von einzelnen Files damit ermitteln und keine Ordner.
Nochmal, ich störe mich selbstverständlich nicht daran, dass eine lokalisierte Konvertierung möglich ist. Ich störe mich aber sehr daran, dass dies der Default ist. Wenn ich lokalisiert ein-/ausgebe, dann sollte ich mir auch bewusst sein, was ich dort tue. Das zum Default zu erklären ist in meinen Augen einfach eine Quelle möglicherweise schwer zu findender Fehler.
Na das ist doch schonmal was.
Um die Größe eines Ordners zu ermitteln, kannst Du zur Not rekursiv über alle darin enthaltenen Dateien iterieren.
Das sagt Dir jetzt aber vermutlich nichts. :-)
Sorry, eine Zeile ist falsch. Hatte einen Tippfehler und habe den vollqualifizierten Namen vergessen.
Muss in Wirklichkeit heißen.