Falscher Event?

Artentus schrieb:

Du solltest übrigens den StreamWriter mit Using deklarieren, ist sauberer.

In etwa so?


Geht zwar - überschreibt mir aber die Einträge - fügt sich also nicht an die nächste freie zeile an.

Hänge an den Konstruktor noch ein True an.

Das wars - perfekt und nochmals danke!

Hi

kai996 schrieb:

btw. nutz bitte statt "vbCrLf" Environment.NewLine
vbCrLf ist einer der Bösen Funktionen

Nein. vbCrLf ist eine Konstante. In VB.Net gibt's keine Escapesequenzen, wie bei C#. In C# könnte man bspw. einfach "a\r\nb\r\n" schreiben und würde den Text
"a
b
"
erhalten. Wie gesagt, das geht in VB nicht, daher drückt man das durch ein + bzw. & vbCrLf aus. Das VB-Äquivalent wäre eben "a" + vbCrLf + "b" + vbCrLf. Da vbCrLf eben eine Konstante ist, kann das bereits zur Kompilierzeit ausgewertet werden, was bei Environment.NewLine nicht der Fall ist, da hier eben Code ausgeführt wird (ist ja eine Property und die Property hat eine Get-Methode, die wiederum in .Net nicht als konstant markiert werden können).

Gruß
~blaze~

Dann hätte ich also "vbCrLf" an ca. 1500 Stellen in meinem Code beibehalten können?

Gute Nacht!

Lass es, es ist im Prinzip egal. Wenn's dir nicht passt, replace es halt global.
Ich bin halt der Meinung, dass wenn man schon in VB programmiert, dass man auch die sinnvollen Sachen beibehalten sollte (d.h. alte VB6--Sachen über Bord werfen, aber das, was halt explizit zur Sprache gehört oder dafür vorgesehen wurde, wie Konvertierungen zwischen Datentypen, CType, Konstanten, die Escapesquenzen ersetzen, etc. beibehalten,)

Gruß
~blaze~

@~blaze~: So zwischendurch: Ich habe CType tatsächlich noch nie benötigt. Bei mir hat DirectCast immer ausgereicht (z.B. beim untypisierten BackGroundWorker-Argument oder bei manchen Vererbungs-Konstruktionen). Ansonsten gibt's eigentlich immer eine passende Konvertierung (z.B. Integer.TryParse oder Convert.ToInt32)

CType benötigst du z.B., wenn du Konvertierungen zwischen zwei ähnlichen Typen hast, die aber nicht das gleiche sind. Da wird dann eben ein Operator verwendet, der folgendermaßen definiert wurde:

Widening bedeutet, dass du eine implizite Konvertierung vornehmen kannst - d.h., dass kein CType vorhanden sein muss, bei Narrowing ist die explizite Angabe der Konvertierung erforderlich.
Der Unterschied zwischen den beiden ist, dass bei DirectCast bereits bekannt ist, dass es sich um eine Instanz des Typs handelt. Das nimmt man dann her, wenn bekannt ist, dass ein Objekt in der Vererbungshierarchie weiter unten ist, als vom Objekt angenommen. Z.B. bei Eventhandlern wird das Objekt sender verwendet. Das kann jetzt bspw. Button.Click behandeln, damit wäre klar, dass sender vom Typ Button sein wird, somit kann man das mit DirectCast erledigen.
Beispiele für CType wären z.B. folgende
- konvertiere einen Zeiger (IntPtr) zu einem Integer
- konvertiere ein Objekt vom Typ T zum Typ Nullable(Of T)
- konvertiere SizeF zu Size (umgekehrt wäre implizit, da Integer problemlos - allerdings ab einem bestimmten Absolutbetrag mit Genauigkeitsverlust behaftet - zu Single konvertiert werden kann, Single aber nicht zwangsweise zu Integer)

Integer.TryParse ist halt nur von Strings möglich und Convert unterstützt wohl das gleiche wie CInt usw. Hab nicht ausgetestet, ob das was anderes kann, als Datentypen.
Die primitiven Datentypen sind vom Operatoren-Verhalten übrigens anders, als die anderen Klassen und Strings bekommen auch eine Extrabehandlung. Während der Operator CType eigentlich eine spezielle Methode mit dem Namen je nach Widening/Narrowing-Angabe entweder op_Implicit oder op_Explicit ist (kann man auch einen Delegaten drauf legen) haben die Datentypen keine solche Methode zwischen den Datentypen selbst. Strings übrigens auch nicht, die Operatoren + und & werden zu String.Concat ausgewertet oder vom Compiler aufgelöst.

Gruß
~blaze~

@~blaze~
Ich habe DirectCast aber auch schon zum Konvertieren einer abgeleiteten Klasse in ihre Basisklasse verwendet. Ist das auch gewollt oder sollte ich das lieber anders machen?

Ist eigentlich unnötig. Im Prinzip ist ja bspw. eigentlich jede Instanz eines Buttons auch ein Control und in die Richtung weiß der Compiler ja, dass das immer so ist.

Gruß
~blaze~

Achso, danke. Dann werde ich das in Zukunft weglassen.

@~blaze~

Super Erklärung.

Danke.
Mir ist übrigens gerade noch ein Fall eingefallen, bei dem man das DirectCast brauchen kann. Bei Interface-Implementierungen gibt's die Möglichkeit, Interface-Member nicht öffentlich zu deklarieren. Wenn man jetzt auf so einen Member zugreifen will, muss man erst zum jeweiligen Interface casten. Ein Beispiel wäre z.B. System.Collections.Generic.LinkedList(Of T) und System.Collections.Generic.ICollection(Of T). ICollection(Of T) hat eine Add-Methode, die in der LinkedList AddLast heißt. Das ist aber auch der einzige Fall, wo das gebraucht werden kann. Wenn man's einer Variable zuweist, wird das dann auch nicht mehr benötigt (und wer verwendet statt der AddLast-Methode dann schon Add). Wo es btw. Sinn macht ist z.B. wenn eine Klasse ICollection(Of T) implementiert und ICollection(Of T) wrappt. Da ICollection(Of T) IEnumerable(Of T) und somit auch IEnumerable implementiert, wird meist die von IEnumerable(Of T) verfügbar gemachte GetEnumerator-Funktion öffentlich sichtbar und die IEnumerable.GetEnumerator-Funktion nicht öffentlich sichtbar gemacht. Da es dann Sache der Basis-ICollection(Of T) ist, wie es IEnumerable und IEnumerable(Of T) behandelt, macht's Sinn, hier auch auf die IEnumerable zurückzugreifen. Beispiele für die ICollection(Of T) sind z.B. Typfilter oder Member-Filter (z.B. dass eine ICollection(Of Color) zu einer Argb-Wert-Collection ICollection(Of Integer) umgewandelt wird).
Wie gesagt, im Normalfall wird's nicht benötigt.

Gruß
~blaze~