1. Ressourcen Dateien der Solution hinzufügen (MyResources.resx, MyResources.resx.de-DE, MyResources.es-ES).
2. Ressourcen Dateien öffnen und den AccessModifier auf Public stellen.
3. Zum Test einen Eintrag erzeugen. Der Key muss dabei in allen Ressourcendateien der selbe sein. Der Value beinhaltet die Übersetzungen.
4. Default Sprache in den Eigenschaften des Projektes unter Assembly Information –>Neutral Language einstellen. Dieses definiert die Sprache in der Ressourcen Datei ohne Culture-Zusatz (MyResources.resx)
5. Die Projektdatei (.csproj) mit einem Editor öffnen und die zusätzlich unterstützten Sprachen dem Tag <SupportedCultures> hinzufügen. <SupportedCultures>de-DE;es-ES;<SupportedCultures>
6. Ein Property erzeugen, dass MyResources bereitstellt:

public class LocalizedStrings
{
    public LocalizedStrings()
    {
    }

    private static var localizedResources = new MyNamespace.MyResources();

    public MyNamespace.MyResources LocalizedResources
    { get { return localizedResources; } }
}

6. In der App.xaml die eben erstellte Klasse bereitstellen:

<Application.Resources>
   <local:LocalizedStrings xmlns:local = "clr-namespace:MyNamespace" x:Key="LocalizedStrings" />
</Application.Resources>

7. Nun fehlt nur noch das Binding

<TextBlock Text="{Binding Path=LocalizedResources.KeyInMyResources, Source={StaticResource LocalizedStrings}}" />

Hinweis zur ApplicationBar:

Da die ApplicationBar keine Silverlight-Komponente ist, wird dynamisches DataBinding nicht unterstützt. Also nicht wundern warum beim Kompilieren eine XamlParseException “AG_E_PARSER_BAD_PROPERTY_VALUE” bekommt. Im Xaml wird die entsprechende Zeile markiert mit dem Hinweis “Text cannot be empty”. Die Lösung lautet: code behind…

public MainPage()
{
   InitializeComponent()
   BuildApplicationBar()
}
private void BuildApplicationBar()
{
   ApplicationBar = new ApplicationBar();
   var appBarButton = new ApplicationBarIconButton(new Uri("/Images/ApplicationIcon.png",UriKind.Relative)){Text = MyResources.MyAppBarButtonKey};
   ApplicationBar.Buttons.Add(appBarButton);

   var appBarMenuItem = new ApplicationBarMenuItem(MyResources.MyMenuItemTextKey);
   ApplicationBar.MenuItems.Add(appBarMenuItem);
}

In seinem Aufruf kritisierte mein Gastgeber das Verwenden von Workarounds bei der Software-Entwicklung. D. h., das Verwenden von kleinen Quelltext-Fragmenten, mit denen Probleme nur auf die Schnelle und nur vordergründig gelöst werden sollen. Stattdessen soll man wie ein guter Pfadfinder bei jeder Gelegenheit die Workarounds wegräumen und Ordnung im Quelltext schaffen — selbst dann, wenn man die Unordnung nicht verursacht hat.

Doch hier regt sich bei mir Widerspruch, so daß ich meinem Gastgeber im Sinne Feyerabends (1997) entgegenrufen möchte: No, anything goes! Denn, um es mit den Worten Paul Feyerabends zu formulieren, kein Programmcode ist “so alt oder so absurd, daß er nicht unser Wissen verbessern könnte. (Feyerabend, 1997, S. 55). Denn woher weiß man den, daß der Workaround, den man da gerade beseitigen will, das Problem ist? Kann es denn nicht auch so sein, daß die Idee, die hinter dem Workaround steckt, die eigentlich bessere ist, als die hinter dem vermeintlich ordentlichen Quelltext? Kann man das vor allem dann wissen, wenn der Quelltext nicht von einem selber ist?

Denn dies setzt voraus, daß man die Absichten und die Ideen des Urhebers richtig erkannt und verstanden hat, was nicht immer der Fall sein muß. Und Aufräumen würde dann die Unordnung, die man dort beseitigen will, erst schaffen. Hier versagt daher die Metapher der Pfadfinderregel. Im Wald mag jeder leicht erkennen, daß ein Faß mit Giftmüll dort nicht hingehört. Aber ein vermeintlicher Workaround, ist am Ende gar keiner, da er nämlich nur das Ergebnis unkonventionellem und unorthodoxem Denken ist, zu  dem man vielleicht selbst aufgrund der ganzen Pfadfinderregeln nicht mehr fähig ist. Denn dies sollte nicht vergessen werden, wenn man nach Ordnung und Clean Code ruft. Software-Entwicklung ist ein kreativer Akt, bei der es auch — wenn nicht sogar primär — um die Entwicklung von Ideen und nicht nur um die sture Produktion von Quelltext.

Wenn ich in diesem Sinne rufe: “Anything goes!”, heißt dies aber auch, daß ich meinem Gastgeber in einem Punkt zustimme. Denn mit  die Software-Entwicklung soll dadurch nicht der Beliebigkeit anheim gestellt werden. Hierfür bedarf es schon einige grundlegender Regeln und Prinzipien, um die Software-Entwicklung zu einem erfolgreichen Abschluß zu bringen. Doch die Regeln und Prinzipen sind abhängig vom Kontext, d. h. von der Anwendungsdomäne und dem Zweck der Software, der Entwicklungsumgebung, den eingesetzte Techniken usw. Und die Regeln und Prinzipien, die in der einen Situation zum Erfolg führten, können in der nächsten versagen. Ein beliebiges und stures anwenden der immer gleichen Regeln und Prinzipien kann genauso schädlich sein, wie eine regel- und prinzipienlose Beliebigkeit.

Literatur
Feyerabend, P. (1997). Wider den Methodenzwang (6. Aufl.). Frankfurt am Main: Suhrkamp.

Es wird automatisch eine Stopwatch erstellt, deren Namen man bei mehreren Stopwatches kurz anpasst. Schnell noch zur Identifizierung im Output-Fenster den Funktionsnamen angeben und fertig ist das Miniprofiling.

Um dieses Snippet nutzen zu können muss es nicht extra mit dem Code Snippets Manager von Visual Studio importiert werden, sondern ist dank des Snippet Editor mit einem Installer ausgestattet.

Time to go back to basics!

Nicht umsonst gehören die “Boy Scout Rule” und “Root Cause Analysis” zu den Basics der Softwareentwicklung. Häufig stolpert man selbst im eigenen Code über ungewöhnlich Variablennamen, Schleifenkonstrukte, “Managerklassen” oder Workarounds. Es genügen häufig kleine Änderungen und der Code wird übersichtlicher und erspart einige Kopfschmerzen beim Debuggen. Insbesondere Workarounds sind gefährlich. Sie erscheinen einem das Leben schnell zu erleichtern und das Problem aus der Welt zu schaffen. Besonders wenn wieder einmal der Chef im Nacken sitzt. Doch die hier gewonnene Zeit wird mit hohen Zinsen erkauft. Wer hat nicht schon einmal ein komplettes Modul neu schreiben müssen? Wird unter die Oberfläche des Problems gesehen und das Übel an der Wurzel gepackt, stellt man zudem oft fest, dass sich ein Problem nicht nur sauberer, sondern viel einfacher lösen läßt als gedacht. Die genannten Prinzipien lassen auch in vielen anderen Bereichen gut nutzen oder wie gut ist euer Schreibtisch aufgeräumt? Oder wiederspricht eurer Meinung nach gar alles dem “Keep It Simple, Stupid”-Prinzip und Prokratinationsstapel sind der beste Weg Ordnung zu halten?

<ComboBox ItemsSource="{Binding Items}"
  DisplayMemberPath="Value"
  SelectedValuePath="Key"
  SelectedValue="{Binding SelectedItemCode}"/>

ViewModel code:

// Key = ItemCode, Value = Name
public IDictionary<string, string> Items{get; private set;}  

public string SelectedItemCode
{
 get
 {
  return Settings.Default.SelectedItemCode;
 }
 set
 {
  if (Settings.Default.SelectedItemCode != value)
  {
   Settings.Default.SelectedItemCode = value;
   OnPropertyChanged("SelectedItemCode");
  }
 }
}

A settings file is used to store the user selection. Of cause you have to save the settings e.g. if your view is closed.

>> 20100618

string Format(String, Object) ermöglicht es ein Text-Pattern zu erstellen in welches die Variablenwerte an den Indexpositionen mit geschweiften Klammern eingefügt werden. Um aus den Integerwerten Datum und Tag immer eine zweistellige Zahl zu erstellen besteht die Möglichkeit durch einen Doppelpunkt ein Format zu spezifizieren. Es gibt Formate für Währung, Exponenten und viele mehr. Das hier benötigte Format ist D, wie  Dezimal gefolgt von der Anzahl der Stellen, die eine Zahl einnehmen soll. Auf das Pattern folgend werden die Variablen übergeben. Im oben gezeigten Beispiel ist Date vom Typ DateTime.