Visual Studio 2012 Metro Styles für WPF–Metro Window Update

Der letzte Schliff für meine Visual Studio 2012 Metro Styles ist natürlich das MetroWindow, was dann wirklich die ganze Anwendung im typischen Grauton erscheinen lässt. Glücklicherweise gibt es bereits ein Projekt, dass sich um die Implementierung eines solchen MetroWindows gekümmert hat, nämlich das MahApps.Metro Projekt. Den Style von dort können wir ganz einfach an unsere Wünsche anpassen, indem wir folgende Resourcen überschreiben:

<Color x:Key="AccentColor">#2D2D30</Color>
<Color x:Key="WhiteColor">#2D2D30</Color>
<Color x:Key="BlackColor">#FFFFFFFF</Color>

Screen1Screen2

AccentColor setzt den Hintergrund der Titelleiste (mit Schließen, Minimieren … Buttons) und WhiteColor legt den Window-Hintergrund fest. Die beiden sind in unserem Fall gleich. BlackColor ist der Vordergrund für das MetroWindow.

Download

Meine Visual Studio Styles sind jetzt auch Teil des MahApps.Metro Projekts und können also vom GitHub Repository mit runtergeladen werden. Wer also den Sourcecode für das MetroWindow und die VS Styles haben möchte, kann sich das Repository hier auschecken. Die VS Styles liegen dann unter MahApps.Metro/Styles/VS, das Beispielfenster findet man unter MetroDemo (wichtig für alle StarTreck Fans: Käptn Kirk schläft immer noch). Für das MahApps.Metro Projekt hab ich zusätzlich noch eine System.Windows.Interactivity-TriggerAction gebastelt, um die Tabs zu schließen, wenn das jemanden interessiert .. im normalen Download ist die aber nicht dabei (der soll ja nur die Styles zeigen).

Ansonsten hab ich natürlich auch den Artikel und den direkten Download aktualisiert, die MahApps.Metro.dll liegt dann im lib Verzeichnis:

Direkter Download

Codeproject Artikel

Dynamischer Rehosted Workflowdesigner für die WF 4 – Teil 3

Rückblick auf Teil 2: Das Storage Module kümmert sich um

  1. Erzeugen eines neuen Workflows
  2. Speichern eines Workflows
  3. Laden eines vorhandenen Workflows
  4. Löschen eines vorhandenen Workflows

abhängig vom ausgewählten Workflowtyp.

In diesem Teil wollen wir uns damit beschäftigen eigene Activities zu bauen, wie das auch der Visual-Studio-Designer macht. Im VS-Designer werden für alle Workflows eigene Typen kompiliert, die dann auch als Black-Boxes in anderen Workflows wiederverwendet werden können bzw. denen Argumente und ein spezielles Aussehen verpasst werden können (wie z.B. bei allen Standardactivities wie Assign, For, Foreach und so weiter). Wir werden dann die Interfaces vom vorigen Teil mit dieser Logik implementieren und damit einen ersten Workflowtyp haben. Dann müssen wir als  letztes noch einen ToolboxService schreiben, der unsere eigenen Activities in die Toolbox lädt. Der fertige Activity-Designer sieht so aus:

Dynamischer Rehosted Workflowdesigner für die WF 4 – Teil 3 weiterlesen

WCF Cluster 1.0

Nach einiger Zeit, möchte ich jetzt endlich die erste Version von meinem WCF-Cluster Beispiel vorstellen. Wie man einen einfachen Client bauen kann hatte ich ja schon im vorigen Artikel geschrieben. Ich lade jetzt auch noch einen Command mit hoch, der Pi berechnet um mal ein richtiges Beispiel mit längerer Ausführungsdauer zu haben.

Der ganze Quellcode ist im Download mit drin, deshalb werde ich hier nicht viel reinkopieren. Das Distributor-Gerüst sieht so aus:

public class ComputingPowerDistributor : IComputingPowerDistributor
{
  public void ExecuteCommand(Stream input)
  {
      calculators.ElementAt(calculatorIndex).Value.ProducerExecuteCommand(input);
  }

  public void Connect()
  { 
     calculators[header.ClientAdress] = new ChannelFactory<IPowerProducerClient>(binding, new EndpointAddress(header.ClientAdress)).CreateChannel();
  }

  public void Disconnect()
  {
      calculators.Remove(header.ClientAdress);
  }
}

Die Producer/Calculator können sich an- und  abmelden, jeder Command, der von einem Consumer kommt wird an einen Producer weitergeleitet. Die Adressen und IDs werden im Header von der Nachricht übertragen.

Dann ist die Funktion von Producer/Consumer eigentlich nur noch Fleißarbeit. Einen WCF-Service im Code erstellen und die Methoden vom Distributor aufrufen. Der Producer ist ja immer gleich, deshalb habe ich dafür mal ein UI geschrieben, das im Moment so aussieht:

p1

Der Test-Conumer, der mitkommt sieht so aus:

p2

Der setzt 50 Commands ab, die bei der Pi-Berechnung mitmachen. Diese Commands werden der Reihe nach vom Distributor auf alle Calculator verteilt. Natürlich ist das noch nicht die Endlösung der Lastverteilung, aber zum Testen funktioniert es ganz gut.

Wenn man mit mehreren Computern arbeitet ist es wichtig vorher die Adresse vom Distributor zu ändern (im Moment als localhost), ansonsten sollte alles so funktionieren.

Als erstes muss man den Distributor Host starten, dann die Power Producer und den Consumer, die dll vom Command liegt schon im bin Verzeichnis.

Und hier ist der Link zum Download: Selen.Clustering