Posts

MonoTouch/Mono for Android: Windows-1252 kodierte Texte lesen und schreiben

Bild
Eines der am nervigsten Themen mit denen man sich beim schreiben von Software rumschlagen muss ist aus meiner Sicht das Thema Encoding . Ich weiß nicht mehr wann ich das erste mal so richtig mit den Problemen konfrontiert wurde, aber es ist gefühlt eine halbe Ewigkeit. Dank Unicode und Co. werden die Probleme bei neuer Software zwar weniger, aber es kommt immer wieder die Situation in denen man Daten einlesen muss welche nicht entsprechend kodiert sind. Als .NET Entwickler hat man durch die Klasse System.Text.Encoding allerdings eine ganz gute Waffe in der Hand um mit den verschiedenen Kodierungen umzugehen. Die Sache wird aber dann wieder “interessanter” wenn verschiedene Plattformen wie z.B. MonoTouch oder Mono for Android  im Spiel sind. In meinem Fall muss ich Daten verarbeiten die mit einem Delphi Programm erzeugt werden. Da der Quellcode der Software vorhanden ist konnte ich sehen, dass die Daten mit der Standard Windows Codepage geschrieben werden (und da die Software nur im

Monotouch - Eigene Views im Interface Builder verwenden

Bild
Auch wenn man, so wie ich, kein großer Freund von Apples Interface Builder ist, so hat es gelegentlich doch einen gewissen Charme User Interfaces für iOS Geräte "mal kurz zusammen zu klicken". Wenn man nur die Standard Elemente, wie Button, WebView usw. verwendet, dann ist das alles auch ganz schnell gemacht. Interessanter wird das ganze, wenn man eine eigene View verwenden möchte. Erstellen einer Custom View Wichtig bei einer Custom View sind die zwei folgende Eigenschaften: Das Register Attribut auf der Klasse Ein Constructor mit folgender Signatur: .ctor(IntrPtr handle) : base(handle) 1: [Register( "MyView" )] 2: public class MyView : UIView 3: { 4: public MyView(IntPtr handle) 5: : base (handle) 6: { 7: this .Initialize(); 8: } 9:   10: private void Initialize() 11: { 12: // Initialization Code 13: } 14: } Verwendung im In

Visual Studio durch eine RAM Disk beschleunigen

Bild
Heute hat mich mein Visual Studio mal wieder durch eine quälende Langsamkeit genervt. Oft gibt sich das nach ein paar Minuten und man kann normal damit arbeiten. Also habe ich mich dann mal auf Ursachen begeben. Die ersten verdächtigen sind dabei immer die Add-Ins und Extension die so installiert sein. Und nachdem mich Visual Studio Achievments als “Extensions Junkie Deluxe” bezeichnet hat, sollte da eigentlich auch Potential da sein und 1-2 Extensions können wahrscheinlich fliegen. Das hat leider auch nicht den gewünschten Erfolg gebracht und ich musste weiter suchen. Nach ein paar Minuten fiel mein Verdacht auf NCrunch und Resharper . Beides auf jeden Fall Tools auf die ich nicht verzichten möchte. NCrunch selbst hat mich dann auf eine gute Idee gebracht: Der Einsatz einer RAM Disk. Ram Disk konfigurieren Nach ein bisschen suchen im Internet bin ich auf DataRam RAMDisk . Die ist für Ram Disks bis zu 4GB kostenlos und läuft auch unter 64-Bit Systemen. Des weiteren lässt sich die

Darstellung von WPF Anwendungen

Bild
WPF Anwendungen haftet immer noch der Ruf an, dass diese "irgendwie komisch" aussehen. Dies liegt vor allem an der Art und Weise wie WPF Text darstellt (vgl. Die Geschichte vom unscharfen Text  oder  Fonts in WPF seem blurry ) Wenn man ein Windows ab Vista verwendet bessert sich das ganze ein bisschen, aber auch hier sehen die Schriften alle nicht wirklich scharf aus (vgl. Alles wird unscharf ). Das ein WPF Anwendung nicht zwangsläufig "unscharf" und "komisch" aussehen muss, sieht man an Visual Studio 2010. Das hatte zwar zu Beta Zeiten auch das Problem, aber nach genug Kritik aus Entwicklerkreisen hat Microsoft es dann doch geschaft eine "scharfe" Version von Visual Studio 2010 auf den Markt zu bekommen. Dafür hat Microsoft ein paar Anpassungen im WPF Text Stack (vgl. WPF 4.0 Text Stack Improvements ) vorgenommen. Leider sind diese Anpassungen nicht per Default für WPF Anwendungen verfügbar. Auch wenn man einen neue Anwendung entwickelt sind

Erste Schritte beim Entwickeln eines Outlook 2010 Add-ins

Bild
Aktuell schreibe ich gerade mein erstes Add-in für Outlook 2010. Der Einstieg ist dank der guten Projektvorlagen von Visual Studio 2010 auch nicht weiter schwer. Einfach ein neues "Outlook 2010 Add-in" anlegen und man kann eigentlich loslegen. Visual Studio 2010 - New Project Nach dem Anlegen erhält man ein Projekt bei dem eigentlich alles schon konfiguriert ist. Einfach "Start Debugging" wählen und Outlook wird gestartet und das Add-in geladen. Seinen eigenen Code kann man in die, von Visual Studio angelegte, Klasse ThisAddIn einfügen. Nach dem Anlegen des Projekts Hier hat man jetzt z.B. die Möglichkeit auf verschiedene Events von Outlook zu reagieren. Neben denen, im Screenshot gezeigten, StartUp und Shutdown von ThisAddIn gibt es über this.Application noch einige weitere. Genauere Informationen darüber sind in der  MSDN (ApplicationEvents_11_Event Events)  zu finden.

NUnit Cheatsheet

Frei nach "Ey Mann, wo ist mein Auto?" kann man sagen, dass NUnit ein sehr großes und mächtiges Unittest Framework ist. Und seine Größe wird nur durch seine Mächtigkeit übertroffen. NUnit ist aber auch sehr gut darin seine Größe und Mächtigkeit zu verbergen. Wenn ich mir die Unittests in meiner Firma gelegentlich so anschaue, dann könnte man meinen NUnit hätte nur die Assert.AreEqual(...) Methode. Eigentlich alle Tests werden über diese Methode realisiert.  Man könnte jetzt doch sagen "Hey, ist doch super. Mann muss sich nur diese eine Methode merken und kann Unittests schreiben". Aus Erfahrung habe ich damit aber zwei Probleme: Man schreibt keine Unittests, da man die Bedingung nicht oder nur umständlich mit einer Prüfung auf Gleichheit "erschlagen" kann. Unittests werden groß und kryptisch wenn man versucht alles mit Assert.AreEuqal(...) zu machen. Hier passt ein Zitat von Paul Watzlawick ziemlich gut:  "Wer als Werkzeug nur einen Hamme