# Sunday, April 20, 2008

Häuser wie Software

Und wieder hat der Code-Inside Blog einen sehr interessanten, diesmal weniger lustigen, weil leider wahren Artikel in seinem Blog veröffentlich. Allerdings hätte ich Mark durch Euro ersetzt; Was aber zeigt, dass das Problem bereits sehr lange bekannt und doch immer noch nicht gelöst wurde.

Sunday, April 20, 2008 12:37:51 PM (W. Europe Daylight Time, UTC+02:00) #  Comments [0] | Trackback
# Friday, April 18, 2008

Excel: Zellen verbinden per Shortcut

Ich musste gerade einige Zellen in Excel verbinden. Da mir das ewige Markieren - Rechtsklick - Zellen Formatieren - Zellen verbinden zu langsam war, habe ich nach einem Shortcut für diese Aktion gesucht. Leider bringt Excel so etwas nicht mit. Aber mit einem kleinen Macro kann man die Funktionalität nachrüsten:

Diese Makro wechselt nach der Zuweisung einer Tastenkombination den Status von mehreren Zellen von Nicht verbunden zu Verbunden und wieder zurück.
Sub Makro2()
    With Selection
        .HorizontalAlignment = xlGeneral
        .VerticalAlignment = xlBottom
        .WrapText = False
        .Orientation = 0
        .AddIndent = False
        .IndentLevel = 0
        .ShrinkToFit = False
        .ReadingOrder = xlContext
        .MergeCells = Not .MergeCells
    End With
End Sub

Friday, April 18, 2008 9:56:58 AM (W. Europe Daylight Time, UTC+02:00) #  Comments [0] | Trackback
# Thursday, April 17, 2008

Bürospielchen - Lange nicht mehr so gelacht

Komme gerade nach einem echt langen Tag nach Hause. Muss auch fast schon wieder zum nächsten Termin, aber will mal schnell schauen, was mein privater Posteingang noch Ansprechendes zu bieten hat. Da dort leider nichts Ansprechendes zu finden ist, stöber' ich noch schnell durch meine RSS-Feeds und finde dabei einen Blogpost von Robert Mühsig. Da ein bisschen Spaß im Büro nie schaden kann, fange ich an zu lesen. Aber vor allem zu lachen. Mit Tränen dabei. Ach, lange nicht mehr etwas so lustiges gelesen. Ich denke, ich werde morgen mal mit Punkt 1.5 beginnen :)

Thursday, April 17, 2008 9:04:56 PM (W. Europe Daylight Time, UTC+02:00) #  Comments [2] | Trackback
# Wednesday, April 16, 2008

Renaming of several Microsoft embedded products

From a post ont the Windows Embedded blog - Microsoft announced some name changes for their embedded products:
  • Windows Embedded CE is now known under Windows Embedded Compact
  • Windows XP Embedded is now known under Windows Embedded Standard
  • Operating systems wich embedded licences are now known under Windows Embedded Enterprise
  • Point of Service applikations and platforms are now known under Windows Embedded POSReady

Wednesday, April 16, 2008 8:44:17 PM (W. Europe Daylight Time, UTC+02:00) #  Comments [0] | Trackback

iX: Muschel verpackt

In der iX 5/2008 schreibt Dr. Holger Schwichtenberg:
Muschel verpackt

Die wegen ihrer Leistungsfähigkeit viel gepriesene PowerShell bietet bisher nur eine unkomfortable Benutzeroberfläche. Microsoft hat es bisher nicht geschafft, der Shell ein angemessenes GUI zu verpassen. Diese Lücke schließt nun das Third-Party-Tool PowerShellPlus.
Ich weiß ja nicht so genau, was Herr Dr. Schwichtenberg unter einer Shell versteht, aber für mich ist eine Shell eher Kommandozeileninterpreter als GUI. Ich denke, damit stehe ich nicht allein. Zugegeben; Ich habe den Artikel noch nicht gelesen und manchmal denke auch ich, dass es ein GUI hier und da etwas einfacher macht. Aber Shell bleibt Shell. Sonst könnte man es ja direkt MMC nennen. Außerdem ist die PowerShell als Ersatz für den Kommandozeileinterpreter cmd.exe gedacht, wenn man der Wikipedia glauben darf.

Wednesday, April 16, 2008 7:27:55 PM (W. Europe Daylight Time, UTC+02:00) #  Comments [0] | Trackback
# Sunday, April 13, 2008

Mit Powershell das EventLog eines Remoterechners überwachen

Mein Blog wird auf einem Windows 2003 Server gehostet. Da ich gerne wissen möchte, was dort so alles passiert, habe ich mir ein kleines Powershell-Script geschrieben, welches mir einmal pro Tag die Eventlog-Einträge des letzten Tages per E-Mail zusendet:

$sys = Get-Eventlog -list | Foreach-Object -process{Get-Eventlog $_.Log} | ?{$_.TimeGenerated -gt [DateTime]::Now.AddDays(-1)} |  ConvertTo-Html
$msg = New-Object Net.Mail.MailMessage("from@my.mail", "to@my.mail", "Daily Eventlog summary", $sys)
$msg.IsBodyHTML = $true
$smtp = New-Object NetMail.SmtpClient("mailserver.my.mail")
$smtp.Send($msg)

Was macht das Script genau?


Zuerst wird per
Get-Eventlog -list
eine Liste der auf dem System vorhandenen Eventlogs erstellt. Das Ergebnis wird an das Foreach-Object-Cmdlet gepipt, welches für jedes Element der Liste die Einträge abfragt:
Foreach-Object -process{Get-Eventlog $_.Log}
Die daraus resultierende Liste von Einträgen wird dann gefilter. Es sollen nur die Einträge weiterverarbeitet werden, die innerhalb des letzten Tages erstellt wurden:
?{$_.TimeGenerated -gt [DateTime]::Now.AddDays(-1)}
Diese Zeile kann auch als
Where-Object {$_.TimeGenerated -gt [DateTime]::Now.AddDays(-1)}
geschrieben werden, aber ? ist einfach etwas schneller.
Die gefilterten Einträge werden dann als HTML
ConvertTo-HTML
in der Variablen $sys gespeichert.
Im nächsten Schritt wird ein System.Net.Mail.MailMessage-Objekt erstellt, welches die HTML-Liste $sys der Eventlog-Einträge als Nachrichtentext übergeben bekommt.
$msg = New-Object Net.Mail.MailMessage("from@my.mail", "to@my.mail", "Daily Eventlog summary", $sys)
Die MailMessage-Instanz ist nötig, da wir eine HTML-Mail versenden wollen.
$msg.IsBodyHTML = $true
Möchten wir PlanText versenden, können wir den Nachrichtentext auch der $smtp.Send()-Methode übergeben.
Um die Mail per smtp.Send versenden zu können, muss erst der SmtpClient instanziiert werden. Im Konstruktor bekommt er den Mailserver übergeben, über der die Nachricht gesendet werden soll.
$smtp = New-Object NetMail.SmtpClient("mailserver.my.mail")
$smtp.Send($msg)


Im nächsten Schritt werde ich daraus ein kleines, konfigurierbares C#-Programm erstellen, das zum Beispiel verschiedene Ereignisquellen ausfiltern kann.

Sunday, April 13, 2008 12:44:37 PM (W. Europe Daylight Time, UTC+02:00) #  Comments [0] | Trackback
# Wednesday, April 09, 2008

Duff's Device

Da ich momentan eher mit C beschäftige, dort allerdings noch ein paar Fragen offen waren, hatte ich heute ein Code Review mit einem "alten Hasen". Dabei gab es eine Menge zu lernen. Als ich später mit meinem PM (der auch aus der C/C++-Welt stammt) das Review besprach, zeigt er mir einen netten kleinen Codeschnippsel: Duff's Device. Ich lasse das hier einmal ohne Erklärung stehen.
n = (anzahl + 3) / 4;
 
switch(anzahl % 4) {
    case 0:        do { ziel[stelle] = quelle[stelle]; stelle++;
    case 3:             ziel[stelle] = quelle[stelle]; stelle++;
    case 2:             ziel[stelle] = quelle[stelle]; stelle++;
    case 1:             ziel[stelle] = quelle[stelle]; stelle++;
                   } while(--n > 0);
}
Für meine C#-Augen war das ja gar nichts. Fallthrough im Switch-Statement. Brrr. Wenn das der Compiler sehen würde ;) Aber C ist eben etwas ganz anderes.

Wednesday, April 09, 2008 9:29:20 PM (W. Europe Daylight Time, UTC+02:00) #  Comments [0] | Trackback
# Tuesday, April 08, 2008

String.Format mit geschweifter Klammer

Mit Hilfe der String.Format-Methode können ja bekanntlich formatierte Einsetzungen in einen String vorgenommen werden. Im Ursprungsstring werden dazu Platzhalter in der Form {0}, {1}, etc eingefügt. Sind allerdings im Formatstring, als dem String, in den die neuen Teile eingesetzt werden, geschweifte Klammern enthalten, werden diese als Formatierungszeichen betrachtet. Aufgefallen ist mir dies bei der Formatierung der Zeichenkette:
#ifndef _BLABLUB_H_
#define _BLABLUB_H_

#  ifdef __cplusplus
  extern "C" {
#  endif /* __cplusplus */
BLABLUB sollte dabei durch den entsprechenden Namen der Headerdatei ersetzt werden. Allerdings hagelte es mit folgendem FormatString bei jedem Versuch, die formatierte Ausgabe zu erzeugen, eine FormatException.
public static string HeaderExklusionStart = "#ifndef {0}"
    + Environment.NewLine
    + "#define {0}"
    + Environment.NewLine
    + Environment.NewLine
    + "#  ifdef __cplusplus"
    + Environment.NewLine
    + "  extern \"C\" {"
    + Environment.NewLine 
    + "#  endif /* __cplusplus */";
Um den Fehler zu beheben, müssen einfach geschweifte Klammern, die ausgegeben werden sollen und somit nicht als Formatierungsanweisungen zu interpretieren sind, doppelt eingefügt werden:
+ "  extern \"C\" {{"

Auf den Fehler hingewiesen hat mich der Artikel Kombinierte Formatierung im MSDN. Prädikat: Wertvoll.
Tuesday, April 08, 2008 12:14:50 PM (W. Europe Daylight Time, UTC+02:00) #  Comments [0] | Trackback

Fehlerkorrektur: String auf ASCII-Reinheit prüfen

In meinem gestrigen Post String auf ASCII-Reinheit prüfen hat sich ein Fehler eingeschlichen. Die öffentliche Eigenschaft Encoding des StreamWriters ist ReadOnly. Um das Encoding des StreamWriters festzulegen, muss dieses im Constructur übergeben werden:
sourceWriter = new System.IO.StreamWriter( sourceFS, Encoding.ASCII );

Tuesday, April 08, 2008 10:00:49 AM (W. Europe Daylight Time, UTC+02:00) #  Comments [0] | Trackback
# Monday, April 07, 2008

String auf ASCII-Reinheit prüfen

Momentan liegt mein beruflicher Schwerpunkt eher auf der Programmiersprache C im Embedded Umfeld. Da dies jedoch nicht meine präferierte Sprache ist und außerdem die Arbeit (Webserverprogrammierung, CGI-Funktionen, etc) auf Grund der Vielzahl von ähnlichen CGI-Funktionen ein bisschen nach Automatisierung riecht, habe ich begonnen, einen Codegenerator zu schreiben.
Ein paar Worte zur Erklärung. Wir haben eine Anwendung mit zentraler Pseudodatenbank, die alle Programmteile als Quelle und Senke nutzen. Ca. 80% der Datenpunkte sollen per Web-Frontend editierbar sein. Um den Programmierer des Web-Frontends nicht mit den Interna des Microcontrollers zu belasten, stellen wir die Datenpunkte über CGI-Funktionen bereit. Somit muss für jeden Datenpunkt eine ähnlichlautende Zugriffsfunktion in C erstellt werden. Lediglich der Datentyp ändert sich. Die Pflege der Datenpunkte erfolgt in einer Excel-Datei, die auch externen Firmen zur Verfügung gestellt wird.
Da es sich bei dem generierten Code um C-Code handelt und die eingesetzte Entwicklungsumgebung keine Quelltexte in Unicode verarbeiten kann, muss ASCII-Code generiert werden. C# verarbeitet jedoch 2 Byte breite Chars und schreibt liebend gern Unicode. Dies wäre an sich kein Problem, da man einem StreamWriter ja über dessen öffentliche Eigenschaft Encoding die Codierung der Daten vorgeben kann. Jedoch sind, warum auch immer, in den Bezeichnern der Datenpunkte Umlaute vorhanden. Diese können jedoch nicht einfach so in ASCII konvertiert werden, da sie dort nicht definiert sind. So kam schnell der Gedanke nach einem eigenen Konverter oder Filter auf.
Aber wie?

Möglichkeit 1 - Regular Expression Match
System.Text.RegularExpressions.Regex regex = 
     new System.Text.RegularExpressions.Regex( "[^\x00-\x7F]" );
 if ( regex.IsMatch( testString ) )
 {
     //Nicht-ASCII-Zeichen gefunden
 }
Mit dieser Regular Expression werden alle Zeichen gefunden, deren Byte-Repräsentation nicht im Bereich 00 bis 7F liegt. Man könnte nun im If-Block ein paar Methoden zur Ersetzung von beispielsweise 'ä' einsetzen. Allerdings werden dann nur diese Zeichen ersetzt, alle anderen müssen anderweitig behandelt werden. Dadurch wird der Programmablauf inkonsistent.
Alternativ könnten diese Zeichen nicht weiter beachtet werden. Dies würde dann entsprechende Lücken in der Ausgabe hinterlassen.
Wird der If-Block jedoch nicht angesprungen, ist der String garantiert frei von Nicht-ASCII-Zeichen.

Möglichkeit 2 - Regular Expression Grouping
Ändert man den regulären Ausdruck von oben ein wenig ab, kann man die gefundenen Zeichen gruppieren. Dies ermöglicht es, eine Match-Collection zu verwenden, die weitergehende Möglichkeiten bietet. Die Syntax für des regulären Ausdrucks für die Gruppierung wäre:
System.Text.RegularExpressions.Regex regex = 
    new System.Text.RegularExpressions.Regex( "(^\x00-\x7F)" );
System.Text.RegularExpressions.MatchCollection matches =
    regex.Matches( testString );
foreach ( System.Text.RegularExpressions.Match match in matches )
{
    //Nicht-ASCII-Zeichen-Gruppe gefunden
}
Dabei stellt das Objekt Match eine ganze Reihe nützlicher Funktionen bereit, so zum Beispiel die Position des Matches im Ursprungs-String oder die Länge des Matches. Es werden nämlich mit dieser Möglichkeit auch Gruppen wie im Beispiel "Hallööö Welt" die Gruppe "ööö" als ein zusammenhängender Treffer erkannt.

Möglichkeit 3 - Die Klasse Encoding
Die Klasse Encoding stellt verschiedene Möglichkeiten bereit, um mit Zeichen und Zeichenketten zu hantieren. Bei dem oben dargestellten Problem war dies mein erster Anlaufpunkt. Jedoch bin ich nach einigen Monaten C-Programmierung hier einem falschen Pferd aufgesessen :). Man beachte nachfolgende Zeile C#-Code und komme bitte nicht auf die Idee, dies irgendwo zu verwenden:
Encoding.ASCII.GetString( (byte[])testString, 0, testString.Length );
Die Methode GetString der Klasse Encoding.ASCII erwartet als ersten Parameter ein Byte-Array. Was würde man also in C machen? Richtig. Wie oben geschrieben, castet man seine Zeichenkette, eigentlich ja nur ein Char-Array in ein Byte-Array. Die Datentypen sind ja jeweils 1 Byte lang. 1 Byte? Ein Char in C#? Und da steckt der Fehler. In C# ist ein Char 2 Byte lang. Stichwort Unicode. Glücklicherweise meckert dies bereits der Compiler an.
Wie dem auch sei. Der Versuch mündete schließlich in folgendem Qullcode:
string testString = "Halööö Welt. Hähähäh!!!";
byte[] byteArray = Encoding.ASCII.GetBytes( testString );
Console.WriteLine( Encoding.ASCII.GetString( byteArray, 0, byteArray.Length ) );
Dieser Codeschnippsel spuckt dann, wie erwartet, einen ASCII-String aus: Hall??? Welt. H?H?H?!!! Wer damit leben kann...

Fazit
Glücklicher Weise übermittelte mir plötzlich ein Kollege die frohe Botschaft, dass die Bezeichner in den nächsten Tagen auf englische Bezeichner umgestellt werden. Also Umlaute ade. Das ist mir in dieser Situation gar nicht unpassend, da mir keine triviale Lösung für das Problem der Konvertierung eines Unicode-Strings in einen ASCII-String bekannt ist. Schließlich müssen einige Dinge beachtet werden, zum Beispiel die CurrentCulture, da wahrscheinlich ein ö in Deutschland einfach durch oe ersetzt werden kann. Ob das im türkischen ebenso möglich ist, weiß ich nicht.

Dieser Beitrag soll zum einen Anregungen geben, wie die Lösung eines solchen Problems angegangen werden kann. Zum anderen ist es ein Aufruf: Falls jemand dieses Problem schon einmal lösen musste, wäre ich (wahrscheinlich nicht ausschließlich) sehr dankbar, seinen Weg kennenzulernen.

Monday, April 07, 2008 9:02:49 PM (W. Europe Daylight Time, UTC+02:00) #  Comments [0] | Trackback