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.
PferdAmHerd schrieb:
will ja kein klugscheißer sein, aber soweit ich das mitbekommen hab, hast du nur eine subform. children ist aber plural. es müsste also MdiChild heißen
a) MdiChild gibt es nicht
b) MdiChildren[0] liefert nur ein child zurück, somit klärt sich die Frage, warum es kein MdiChild gibt
Ich glaube das ist dann geklärt
Habe das Problem jetzt anders gelöst: Ich hab den Timer jetzt doch in die Hauptform integriert, geht genauso gut.
Danke trotzdem für eure Hilfestellung!
Konrad Rudolph schrieb:
Klar. Es ging dem OP doch, denke ich, darum, Deklaration und Definition öffentlichen Schnittstelle voneinander zu trennen, um, wie in C++, eine Datei quasi mit der Dokumentation der Klasse zu erhalten.
Du hast Recht. Ich hatte das "public" übersehen.
Hallo
Konrad Rudolph schrieb:
chrische5 schrieb:
Übrigens würde ich bei .net und c# auf die Ungarische Notation verzichten, weil selbst Microsoft da nicht mehr macht.
Der Grund ist aber nicht besonders toll. Microsoft macht jede Menge Mist. Außerdem gibt es bessere Gründe, nämlich, dass es einfach nicht mehr notwendig ist, weil die .NET-Sprachen (in der Regel) streng typisiert sind und die Ungarische-Notations-Kürzel damit überflüssige Informationen enthalten.
Ich hätte natürlich auch andere Gründe nennen können (wie auch gerade im MFC-Forum geschehen), aber ich dachte da es für einen Anfänger erstmal gut zu wissen ist, dass diese Notation nicht das Einzige auf der Welt ist und das selbst die Erfinder sie nicht mehr immer benutzen.
chrische
Da habe ich das Problem dass bei Funktionen weiter oben im Code mittels StringBuilder Strings deklariert werden und diese Funktionen dann nicht mehr gehen. Kann man die DLL-Import-Anweisung lokal in einer Methode verwenden? Dann wäre es kein Problem mit 2 Unterschiedlichen...
dEUs schrieb:
Es gibt da immer so eine schöne Analogie zur deutschen Sprache. Der Satz "Die Sonne ist rosa." ist syntaktisch korrekt - keine Rechtschreibfehler und Grammatikfehler - semantisch aber nicht: Er ergibt keinen Sinn.
Nein, auch semantisch ist dieser Satz korrekt, er ist einfach nur falsch. Ein semantisch falscher Satz wäre folgender:
Noam Chomsky schrieb:
„Farblos grüne Ideen schlafen wütend.“
uiuiui *g*
Ja, ich habe den Quellcode. Und ich bin eigentlich kein Fan von Code-Generatoren, nicht umsonst hat man in C# die Makros abgeschafft...
Aber dann wird mir wohl nichts anderes übrigbleiben...
Versuch mal folgendes:
1. Systemsteuerung -> Anzeige -> Designs -> Windows XP
2. Systemsteuerung -> Anzeige -> Einstellungen -> Farbqualität -> Höchste (32bit)
Wenn's nicht tut, poste bitte mehr Details zu dem Rechner, auf dem's nicht tut.