2009-04-05 6 views
5

In meinem Programm habe ich drei verschiedene UI-Zustände (Normal, Erfolg und Fehler) und in jedem sind die Steuerelemente sichtbar/versteckt, aktiviert/deaktiviert, die Farben ändern sich, Etiketten sagen verschiedene Dinge ... etc. und in meinem code-behind möchte ich grundsätzlich ChangeWindowState (UI.Normal) sagen können;Was ist der beste Weg, um einen UI-Zustandsautomaten zu implementieren?

Also meine Frage ist, wie am besten die Kontrolle Änderungen für jeden Zustand zu implementieren?

Natürlich könnte ich die Steuerelemente im Code-Behind manuell ändern, aber ich frage mich, ob es vielleicht einen besseren Weg gibt, wpf Themen oder Stile zu verwenden. Dann könnte ich vielleicht das Fenster so einstellen, dass es das "Error" -Thema verwendet, das ich vordefiniert habe. Ich verstehe sie im Moment nicht wirklich, daher kann ich die Terminologie falsch gebrauchen, aber ich würde mich freuen, wenn mir jemand in die richtige Richtung zeigen könnte, wie man so etwas am besten macht.

Danke!

Antwort

5

Es gibt natürlich viele Möglichkeiten, dies zu erreichen. Wenn Sie ein "Objektmodell" im Programmzustand hatten, könnten Sie eine Kombination aus DataTemplates und DataTriggers verwenden. Unter der Annahme, dies ist nicht der Fall, hier ist ein anderer Ansatz: Sie zu einem Fenster bezeichnet, so dass Sie eine „Abhängigkeitseigenschaft“ in dem Fenster Klasse wie folgt definieren:

public partial class Window1 : Window 
{ 
    public Window1() 
    { 
     this.InitializeComponent(); 

     // Insert code required on object creation below this point. 
    } 

    public ProgramStatus ProgramStatus 
    { 
     get { return (ProgramStatus)GetValue(ProgramStatusProperty); } 
     set { SetValue(ProgramStatusProperty, value); } 
    } 

    // Using a DependencyProperty as the backing store for ProgramStatus. This enables animation, styling, binding, etc... 
    public static readonly DependencyProperty ProgramStatusProperty = 
     DependencyProperty.Register("ProgramStatus", typeof(ProgramStatus), typeof(Window1), new UIPropertyMetadata(null)); 
} 

public enum ProgramStatus 
{ 
    Normal, 
    Success, 
    Error 
} 

Jetzt können Sie ziemlich viel ändern jede Eigenschaft irgend Element des Fensters (einschließlich des Fensters selbst), entweder durch direkte Bindung oder einen Trigger. Hier ist ein Beispiel für die Hintergrundfarbe des Fensters zu ändern über eine Eigenschaft Trigger:

<Window 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:l="clr-namespace:Test" 
    x:Class="Test.Window1" 
    x:Name="Window" 
    Title="Window1" 
    Width="640" Height="480"> 
    <Window.Style> 
     <Style TargetType="{x:Type l:Window1}"> 
      <Style.Triggers> 
       <Trigger Property="ProgramStatus"> 
        <Trigger.Value> 
         <l:ProgramStatus>Error</l:ProgramStatus> 
        </Trigger.Value> 
        <Setter Property="Background" Value="Red" /> 
       </Trigger> 
       <Trigger Property="ProgramStatus"> 
        <Trigger.Value> 
         <l:ProgramStatus>Normal</l:ProgramStatus> 
        </Trigger.Value> 
        <Setter Property="Background" Value="Blue" /> 
       </Trigger> 
       <Trigger Property="ProgramStatus"> 
        <Trigger.Value> 
         <l:ProgramStatus>Success</l:ProgramStatus> 
        </Trigger.Value> 
        <Setter Property="Background" Value="Green" /> 
       </Trigger> 
      </Style.Triggers> 
     </Style> 
    </Window.Style> 
    <Grid x:Name="LayoutRoot"/> 
</Window> 
1

Für diese Art von Sache habe ich so ziemlich immer eine "UpdateUI()" -Funktion gemacht. Diese Funktion betrachtet den Status der Modell-/Elementeigenschaften/Status und aktiviert/deaktiviert/blendet/zeigt, was auch immer. Der Versuch, diesen Code zu verbreiten, führt immer zu einem Problem (so legt "ChangeWindowsState (..)" wirklich nur eine Eigenschaft fest und ruft dann "UpdateUI()" auf).

Ich habe ein paar Versuche gesehen, dies in einer generischen Weise zu behandeln ... aber keiner, den ich wirklich mochte (zum Beispiel das WTL-Zeug). Im Allgemeinen sind diese nicht schlecht implementiert ... aber einfach, schnell zu übertreffen, was sie tun können. Und im Allgemeinen ist die Zustandslogik wichtig genug, dass eine explizite Codierung mit einfacher if/then/else-Stillogik zu weniger Verwirrung führt (Wartung, Debugging usw.).