Hi!
ich habs jetzt mal mit der statischen Klassenvariablen ausprobiert und ich bin zu dem Schluss gekommen, dass es so einfacher ist.
Vielen Dank und Viele Grüße, Gast2
Die anderen Fragen hast Du Dir ja schon selbst beantwortet (das .NET-Verhalten scheint buggy zu sein?).
Coder2 schrieb:
Dann noch die Sache mit dem Split: Was passiert mit Texten, wo nur \n ist, wird das dann auch funktionieren?
Ja. Das char-Array sorgt dafür, dass jeder der dort angegebenen Chars ein mögliches Split-Zeichen ist (d.h. sowohl Unix-, als auch Windows- und Mac-Style-Zeilenumbrüche werden erkannt). Dadurch würden natürlich für einen Windows-Zeilenumbruch (\r\n) ein leerer Eintrag erzeugt, der aber durch den letzten Parameter des Aufrufs entfernt wird.
mono-project.org faq schrieb:
Can Mono run binaries produced by Visual Studio?
Yes, Mono can run binaries produced by Visual Studio, there is no need to recompile.
Generell scheint mono .net2.0 in meinen Augen gar nicht soo übel hinterher zu sein:
http://mono.ximian.com/class-status/mono-HEAD-vs-fx-2/
...speziell Windows.Forms ist eigentlich ziemlich weit.
Hallo!
Vielen Dank! Jetzt funktioniert es wunderbar und ich hab sogar noch n bisschne was gelernt ;-))
Finde cool, dass ihr auch Anfängerfragen beantwortet und man sich nicht unbedingt registrieren muss um hier zu posten!
Danke nochmals, ciao
Nochmal der Vollständigkeit halber: der obige Code ist ja nur fast richtig. Daher hier mal das genaue Äquivalent dessen, was ein using-Block macht:
{
SomeClass idisp = new SomeClass();
try {
// Do something.
}
finally {
if (idisp != null)
idisp.Dispose();
}
}
firefly schrieb:
Rodney: Um die eingelesenen Unicode-Escapesequenzen im Programm zu darstellbaren Einzelzeichen zu konvertieren, langt es, wenn du die hex zahl nach dem "\u" in eine Zahl(z.b. Int32) konvertierst und den Zahlenwert als "Char" weiter verarbeitest.
Super, danke! Genau soetwas habe ich gesucht, ich habe nur versucht mit diesem 4stelligen Code irgendwie ein Char zu erstellen und bin nicht darauf gekommen, dass vorher in ein Int32 zu konvertieren.
Gruß, Rodney
ser1al_ausgeloggt schrieb:
sorry, aber das kann ich so nicht bestätigen, da ich diese tests schon gemacht habe!
Dann hast Du beim Testen einfach Fehler gemacht. Die „nicht-optimierte“ Variante ist *definitiv* schneller, weil der Compiler hier erkennt, was man vorhat und den Aufruf abwandelt, sodass erstens der Vergleich auf x.Length flachfällt (der wird aber sowieso geinlined, fällt also nicht ins Gewicht) und außerdem entfernt der Compiler (nur hier!) die Array-Range-Checks, weil er sicher ist, dass nie ein ungültiger Index verwendet werden kann.
Das behauptet zumindest Anders Hejlsberg, der Chefentwickler des C#-Compilers. Es gibt dazu aber auch Analysen im Netz, die das empirisch bestätigen.
(btw wurde mir die optimierung auch in einigen fachbüchern empfohlen)
Leider sind viele Fachbücher einfach schlecht oder nicht aktuell.
Und zusätzlich, um es nochmal zu betonen: Properties können vom JITTer trivial geinlined werden (und werden dies auch). Den Wert von 'x.Length' zwischenzuspeichern ist also wirklich überflüssig.
Streamer schrieb:
Aber ich finds schon etwas doof, dass ich erst den Text einlesen muss, bevor ich weiß was es für ein Format ist, aber das ist nicht schlimm
Eigentlich gibt es garkeine Möglichkeit, das Encoding festzustellen, wenn die Datei kein BOM und keine sonstigen Formatangaben hat. Denn woher soll das Framework bitte wissen, ob eine binäre 163 ein Pfundsymbol in Latin-1 oder ein lappisches G in Latin-6 darstellt?
Deshalb kann man die Codierung ja auch beim Öffnen schon angeben
EDIT:
Für die zweite Frage gilt im Grunde dasselbe. Du kannst höchstens schauen, ob in der Datei nicht darstellbare Zeichen (< 32) enthalten sind. Aber es kann durchaus auch Binärdateien geben, die nur darstellbare Zeichen enthalten, oder Textdateien wo sich mal ein Binärwert zwischenmogelt (z.B. bei Logausgaben).
Ja danke sehr, das mit dem if war halt nurn Prototyp. Den ganzen kram brauch ich fürn Schulprojekt das mir aufgehalst wurde in dem ich ein Java Applet nachbasteln muss.
Nochmal Danke
MfG Kapp.Sparda
Ja, das ist richtig, man kann diese kleinen Ballon-Meldungen, die rechts unten über dem Systray erscheinen, deaktivieren. Wo genau das unter Windows geht, weiß ich nicht, wenn ich das richtig im Hinterkopf habe geht es aber auf jeden Fall über XP Antispy.
joa, muss schon sagen, äußerst genaue Fehlerbeschreibung...
Aber ich vermute mal es liegt am PixelFormat, beim laden des Bildes oder beim Klonen oder sonst wo gibt es immer ne Überladung die die Enumeration System.Drawing.Imaging.PixelFormat nimmt, da nimmste Format32bppArgb.
Der Fehler kann natürlich ganz wo anders liegen, aber wenn ich raten soll, sag ich das.