WPF

[AOP] UI e dintorni con PostSharp

Dario Santarelli — Sun, 16 Oct 2011 21:29:26 GMT

L’AOP ormai sta diventando un paradigma di programmazione sempre più diffuso specialmente nel mondo .NET dove strumenti come PostSharp, DotSpect (Compile-time static injection) e Spring.NET, Castle Windsor, Enterprise Library Policy Injection Application Block (Dynamic Proxy) rendono sempre più semplice la gestione dei “cross-cutting concerns” che provengono dal mondo Object-Oriented. Personalmente sono stato sempre un entusiasta di PostSharp e in questo post vorrei citare un paio di aspect che ho sempre valutato positivamente nella gestione di codice “vicino” alla UI, specialmente nel mondo Windows Forms e WPF.

Il primo aspect ha a che vedere con il DataBinding. Sappiamo tutti come implementare l’interfaccia INotifyPropertyChanged sia noioso ed anche a fronte di snippet per velocizzare il processo di scrittura il risultato che otteniamo si allontana dall’idea di avere codice (almeno) esteticamente “impeccabile”. Per questo l’aspect che PostSharp introduce a riguardo è tanto semplice quanto geniale in quanto permette, tramite un banale attributo, di agganciare l’implementazione dell’interfaccia INotifyPropertyChanged ad un oggetto ed eventualmente alle sue specializzazioni. Ad esempio, se definissimo un oggetto Customer nel seguente modo…

[NotifyPropertyChanged] 
public class Customer 
{

   public string Name { get; set; }   
   public string Surname { get; set; }   
   public string Email { get; set; }
   ...

…tramite l’attributo [NotifyPropertyChanged] impostato a livello di classe otteniamo nell’assembly di output una injection della solita implementazione dell’interfaccia INotifyPropertyChanged. L’ implementazione dell’aspect, riportata anche nel sito di PostSharp, è la seguente…

[Serializable] 
[IntroduceInterface(typeof(INotifyPropertyChanged),OverrideAction = InterfaceOverrideAction.Ignore)] 
[MulticastAttributeUsage(MulticastTargets.Class, Inheritance = MulticastInheritance.Strict)] 
public class NotifyPropertyChangedAttribute : InstanceLevelAspect, INotifyPropertyChanged 
{           
  [ImportMember("OnPropertyChanged", IsRequired = false)]    
   public Action<string> OnPropertyChangedMethod;           

  [IntroduceMember(Visibility = Visibility.Family, 
                   IsVirtual = true, 
                   OverrideAction = MemberOverrideAction.Ignore)]    
  public void OnPropertyChanged(string propertyName)    
  {      
    if (this.PropertyChanged != null)       
    {          
      this.PropertyChanged(this.Instance, new PropertyChangedEventArgs(propertyName));       
    }    
  }           

  [IntroduceMember(OverrideAction = MemberOverrideAction.Ignore)]    
  public event PropertyChangedEventHandler PropertyChanged;            

  [OnLocationSetValueAdvice]    
  [MulticastPointcut(Targets = MulticastTargets.Property, Attributes = MulticastAttributes.Instance)]    
  public void OnPropertySet(LocationInterceptionArgs args)    
  {                   
    if (args.Value == args.GetCurrentValue()) return;       
    args.ProceedSetValue();       
    this.OnPropertyChangedMethod.Invoke(args.Location.Name);    
  } 
}

Il codice è abbastanza autoesplicativo. La feature degna di nota in particolare è la possibilità di estendere automaticamente questo aspect anche alle classi ereditate semplicemente impostando a livello di classe MulticastAttributeUsage.Inheritance = MulticastInheritance.Strict.

Un altro aspect che ho sempre ritenuto molto utile ha a che vedere con il thread dispatching, ovvero con la gestione dell’esecuzione di un metodo sul thread dell’interfaccia piuttosto che su un worker thread (es. in WPF controllando il thread associato al DispatcherSynchronizationContext corrente). Anche in questo ambito PostSharp permette di definire due attributi [OnGuiThread] e [OnWorkerThread] a livello di metodo, che iniettano la comune logica di controllo del SynchronizationContext in modo da forzare l’esecuzione del metodo rispettivamente sul thread dell’interfaccia o su un thread secondario (link al codice sorgente).
Come risultato, diventa molto semplice applicare questi aspect anche su codice legacy.

[OnWorkerThread] 
void SaveCustomer() 
{    
  Customer.Save();    
  ShowMessage("Customer Saved!");

}  

[OnGuiThread] 
void ShowMessage(string message) 
{ 
  MessageBox.Show(message); 
}

Il pacchetto di istallazione di PostSharp (disponibile anche su NuGet) aggiunge a Visual Studio due toolbox veramente utili: l’Aspect Browser che ci permette navigare su quelli che sono gli aspect utilizzati nell’intera solutione e l’ Affected code toolbox che ci riassume tutte le classi e i metodi che sono soggetti ad aspects. Inoltre, l’intellisense viene esteso in modo da visualizzare dei summary sulle static injections che gli aspect introducono nell’assembly. Ad esempio, per quanto riguarda il precedente aspect NotifyPropertyChanged, i tooltip che otteniamo sono i seguenti:

Technorati tags: AOP,WPF,GUI

[WPF] Drag and Drop con Rx

Dario Santarelli — Thu, 25 Aug 2011 17:27:33 GMT

Le Reactive Extensions (Rx) del framework .NET sono un set di API dedicate a ciò che nella letteratura prende il nome di “reactive programming”. Rx nasce dalla distinzione di due scenari:

pull: un programma agisce estraendo dati dall’ambiente in modo interattivo (es. un’iterazione su una sequenza di dati prelevati dall’ambiente).
push: un programma reagisce ai dati che l’ambiente “spinge” verso di esso (es. un event-handler è un esempio di reazione in uno scenario push)

Data questa distinzione, Rx si basa sulla dualità tra il pattern Iterator e il pattern Observer. In breve, il pattern Observer in uno scenario push è analogo al pattern Iterator in uno scenario pull. Nel pattern Iterator, infatti, l’Iterator è l’attore che accede all'insieme degli elementi di un contenitore in modo interattivo. Il pattern Observer può essere interpretato in modo equivalente se si considera che l’ambiente genera spontaneamente i singoli elementi e li spinge verso il programma, ad esempio attraverso eventi. Quando uno stesso evento viene scatenato più volte, di fatto viene prodotta una sequenza di elementi di tipo “evento”, il che rende ovvia a questo punto la relazione con il pattern Iterator. Rx è stato introdotto quindi per mettere a disposizione degli sviluppatori un modello di programmazione push-based, duale rispetto al ben più conosciuto pull-based, pur non aggiungendo nulla di nuovo rispetto a quest’ultimo. Semplicemente, il modello push-based offre modi diversi se non più semplici per approcciare problemi comuni legati alla programmazione asincrona ed alla composizione di eventi.

Rx implementa il pattern Observer tramite le due interfacce IObserver<T> e IObservable<T>, corrispondenti a IEnumerator/IEnumerable del pattern Iterator. IObservable<T> costituisce una sorta di “collezione asincrona” di elementi (generati in momenti diversi quando si parla di eventi). La relazione tra IObservable<T> e IObserver<T> si trova nel fatto che ad un IObservable<T> è possibile registrare uno o più IObserver<T> (tramite il metodo IObservable<T>.Subscribe(IObserver<T> observer) ). IObserver<T> possiede tre metodi: OnNext(…), OnCompleted() e OnError(…). Essi vengono invocati dall’ IObservable<T> rispettivamente quando possiede nuovi dati, completa un’operazione e si verifica un errore.

Drag and Drop e LINQ-to-events

Nella pratica, uno dei (classici) casi in cui Rx mostra la sua potenza è nell’implementazione del Drag and Drop di un oggetto grafico. Infatti, a differenza delle comuni soluzioni event-based che intercettano eventi e sincronizzano variabili di stato con lo scopo di aggiornare correttamente la posizione dell’oggetto grafico, le Reactive Extensions consentono di convertire gli eventi .NET di interesse in sequenze osservabili che possiamo interrogare tramite query LINQ. Vediamo un esempio concreto. Uno dei classici approcci per implementare il drag and drop in WPF (come in Windows Froms o Silverlight) si basa sostanzialmente sulla sincronizzazione di tre eventi logici di un oggetto grafico: MouseDown, MouseUp e MouseMove. Nello specifico, in WPF, supponendo di avere il seguente XAML…

<Window x:Class="WebRequestWithRxSample.MainWindow"

        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

        Title="MainWindow" Loaded="Window_Loaded">

    <Canvas>

        <StackPanel Name="myPanel">

            <Rectangle Fill="Maroon" Width="100" Height="100" />

        </StackPanel>

    </Canvas>

</Window>

… per gestire il drag and drop dello StackPanel “myPanel” potremmo sincronizzarne i tre eventi MouseLeftButtonDown, MouseLeftButtonUp e MouseMove in modo da gestirne il riposizionamento nel Canvas per ogni evento MouseMove compreso temporalmente tra un MouseLeftButtonDown ed un MouseLeftButtonUp. Quindi, ogni volta che si verifica l’evento MouseLeftButtonDown, per ogni successivo evento MouseMove aggiorniamo la posizione dello StackPanel all’interno del Canvas, tenendo conto della posizione del cursore relativa all’angolo in alto a sinistra dello StackPanel. Il tutto finché non viene scatenato l’evento MouseLeftButtonUp.

Point relativeMouseDownPosition = new Point();

myPanel.MouseLeftButtonDown += (s, e) =>

{

if (myPanel.CaptureMouse())

{

relativeMouseDownPosition = e.GetPosition(myPanel);

}

};

myPanel.MouseLeftButtonUp += (s, e) => { myPanel.ReleaseMouseCapture(); };

myPanel.MouseMove += (s, e) =>

{

if (myPanel.IsMouseCaptured)

{

Point absoluteMousePosition = e.GetPosition(this);

Point newPanelPosition = new Point(absoluteMousePosition.X - relativeMouseDownPosition.X,

absoluteMousePosition.Y - relativeMouseDownPosition.Y);

Canvas.SetLeft(myPanel, newPanelPosition.X);

Canvas.SetTop(myPanel, newPanelPosition.Y);

}

};

Il codice qua sotto implementa la stessa cosa tramite Rx. All’inizio la sintassi può sembrare un po’ meno chiara, ma con il tempo ci si accorge di come in realtà sia molto più leggibile e soprattutto manutenibile rispetto al codice precedente, in quanto si basa su un modello “push” query-based.

 var relativeMouseDownPositions = Observable.FromEventPattern<MouseButtonEventArgs>(myPanel, "MouseLeftButtonDown")

                                      .Do(evt => myPanel.CaptureMouse())

                                             .Select(evt => evt.EventArgs.GetPosition(myPanel));

 var mouseUpEvents = Observable.FromEventPattern<MouseButtonEventArgs>(myPanel, "MouseLeftButtonUp")

                           .Do(evt => myPanel.ReleaseMouseCapture());

 var absoluteMousePositions = Observable.FromEventPattern<MouseEventArgs>(myPanel, "MouseMove") 
                                        .Select(evt => evt.EventArgs.GetPosition(this));

 IObservable<Point> dragPoints = from relativeMouseDownPosition in relativeMouseDownPositions

                                 from absoluteMousePosition in absoluteMousePositions.TakeUntil(mouseUpEvents)

                                 select new Point(absoluteMousePosition.X - relativeMouseDownPosition.X,

                                                  absoluteMousePosition.Y - relativeMouseDownPosition.Y);

 

 dragPoints.ObserveOn(SynchronizationContext.Current).Subscribe(point =>

    Canvas.SetLeft(myPanel, point.X);

    Canvas.SetTop(myPanel, point.Y);

});

Alcune considerazioni

La prima cosa che salta all’occhio è come sia possibile convertire un evento .NET in una sequenza osservabile tramite il metodo Observable.FromEventPattern(…) , il quale permette di specificare il tipo di EventArgs dell’evento, l’oggetto che espone l’evento da convertire ed il nome dell’evento. In particolare, la seconda riga di codice denota come sia possibile convertire l’evento MouseLeftButtonUp dello StackPanel in una sequenza osservabile di tipo IObservable<EventPattern<MouseButtonEventArgs>>.
Rx definisce un suo set di extension methods per comporre sequenze osservabili nello stesso modo in cui LINQ to Objects compone sequenze enumerabili. Ad esempio, il metodo Observable.TakeUntil<TSource, TOther>(…) ritorna tutti gli elementi della sequenza osservabile sorgente finché l’altra sequenza osservabile non produce un valore. Nel nostro esempio, questo extension method è stato usato per filtrare gli eventi MouseMove tra un evento MouseLeftButtonDown ed un MouseLeftButtonUp.
Il metodo Observable.ObserveOn<TSource>(…) permette di fare in modo che le notifiche asincrone agli observer vengano effettuate su un thread o uno scheduler specificato. Nel mondo WPF, come in altre piattaforme che supportano un SynchronizationContext, per evitare eccezioni cross-thread quando si interagisce con la UI di solito si interagisce con il contesto di sincronizzazione tramite la chiamata ObserveOn(SynchronizationContext.Current) che in WPF in particolare è costituito da un oggetto di tipo DispatcherSynchronizationContext.

Note di installazione: se stiamo lavorando su Visual Studio 2010, il modo più veloce per integrare Rx nel nostro progetto è NuGet. Digitando “Rx” sulla textbox di ricerca dovremmo ottenere la seguente schermata. In particolare, il package Rx-Main referenzia l’assembly System.Reactive.dll mentre il package Rx-Testing referenzia l’assembly Microsoft.Reactive.Testing.dll.

[WPF 4.0] Esportare dati dal controllo DataGrid

Dario Santarelli — Tue, 16 Nov 2010 00:40:04 GMT

Il controllo DataGrid di WPF 4.0 permette di ottenere “gratis” l’esportazione dei dati associati alla griglia in diversi formati tra cui plain text, CSV e HTML. Tale funzionalità è esposta semplicemente tramite l’invocazione del comando Copy sul controllo, che trasferisce nella Clipboard i dati contenuti nelle celle selezionate, supportando i formati sopra citati (ovviamente i formati CSV e HTML sono i più interessanti nell’ottica dell’esportazione verso altre applicazioni). Nel seguente esempio viene mostrato come generare un file CSV contenente tutte le righe visualizzate in un DataGrid, includendo le intestazioni di colonna sulla prima riga.Il codice è veramente banale:

myDataGrid.SelectAllCells();
myDataGrid.ClipboardCopyMode = DataGridClipboardCopyMode.IncludeHeader;
ApplicationCommands.Copy.Execute(null, myDataGrid);
myDataGrid.UnselectAllCells();
string csvData = (string)Clipboard.GetData(DataFormats.CommaSeparatedValue);
Clipboard.Clear();
using (StreamWriter writer = new StreamWriter("C:\\test.csv")) { writer.Write(csvData); }

Se invece si sceglie l’HTML come formato di esportazione, ci dobbiamo attendere un simpatico header aggiuntivo collocato fuori dal DOM che indica dove iniziano e dove finiscono le differenti porzioni di dati. Si possono utilizzare tali informazioni per esportare sia una pagina web intera piuttosto che soltanto il frammento relativo alla tabella dati da inserire eventualmente in un’altro documento. In questo caso l’esempio precedente va semplicemente modificato specificando DataFormats.Html come formato di estrazione dati dalla clipboard. Il risultato che otteniamo è il seguente:

Version:1.0

StartHTML:00000097

EndHTML:00000672

StartFragment:00000133

EndFragment:00000636

<HTML>

<BODY>

</HTML>

Tag di Technorati: WPF,DataGrid

[WPF] TextBox e input filtering

Dario Santarelli — Tue, 07 Sep 2010 22:13:49 GMT

Quando si realizza un’interfaccia grafica per l’inserimento dati, è sempre buona prassi prevedere una prima "validazione" dell'input utente. Una tecnica molto semplice per raggiungere tale obiettivo potrebbe basarsi sull’idea di filtrare l’input in modo da non permettere l’inserimento di caratteri non validi. Nel caso della TextBox, in particolare, si potrebbe pensare di estendere il controllo affinché il filtraggio avvenga a fronte di un matching con un generica espressione regolare… una RegexTextBox dunque :).

public class RegexTextBox : System.Windows.Controls.TextBox
{                
  public string Pattern { get; set; }
 
  public RegexTextBox()
  {
     CommandBinding pasteCommandBinding = new CommandBinding(ApplicationCommands.Paste);
     pasteCommandBinding.CanExecute += delegate(object sender, CanExecuteRoutedEventArgs e) 
     { 
       e.Handled = !IsValid(Clipboard.GetText()); 
     };
     this.CommandBindings.Add(pasteCommandBinding);
  }
        
  protected override void OnPreviewTextInput(System.Windows.Input.TextCompositionEventArgs e)
  {                        
     string newText = Text + e.Text;
     e.Handled = !IsValid(newText);            
     base.OnPreviewTextInput(e);
  }
 
  private bool IsValid(string text)
  {
     if (string.IsNullOrEmpty(text)) return true;
     return new Regex(Pattern).IsMatch(text);
  }
}

Un esempio di utilizzo potrebbe essere il seguente (ammissione di soli numeri naturali):

<src:RegexTextBox Pattern="^[0-9]+$"></src:RegexTextBox>

Nel codice sopra riportato viene mostrata anche un’ accortezza che può risultare utile, ovvero il filtraggio dell’input in caso di operazioni di Cut/Copy and Paste. Tale controllo avviene agganciando la nostra RegexTextBox all’application command ApplicationCommands.Paste, in modo da poter validare il contenuto della clipboard.

Technorati Tags: WPF,TextBox

[WPF] Evidenziare testo in una RichTextBox

Dario Santarelli — Tue, 24 Aug 2010 23:01:53 GMT

Una funzionalità fondamentale per text-editor/reader è l’evidenziazione programmatica di testo, magari utilizzando stili di formattazione diversi. In questo post vorrei mostrare una possibile implementazione di tale funzionalità utilizzando il controllo RichTextBox di WPF. Immaginando un approccio top-down, potremmo partire da un metodo HilightText(…), il cui compito sia proprio quello di evidenziare del testo all’interno di una RichTextBox.

public void HilightText(string pattern) 

{              

  List<TextRange> ranges = GetMatchingTextRanges(pattern); 

  foreach (TextRange textRange in ranges) HilightTextRange(textRange, Brushes.Black, Brushes.Yellow);             

}

L’idea è quella di applicare un background giallo ed un foreground nero a tutti gli intervalli di testo (TextRange) che soddisfano un dato pattern-matching.

private void HilightTextRange(TextRange textRange, Brush foregroundBrush, Brush backgroundBrush) 

{ 

  if (foregroundBrush != null) textRange.ApplyPropertyValue(TextElement.ForegroundProperty, foregroundBrush); 

  if (backgroundBrush != null) textRange.ApplyPropertyValue(TextElement.BackgroundProperty, backgroundBrush); 

}

Ora ci troviamo di fronte all’esigenza di determinare gli intervalli di testo coinvolti nel matching. Definiamo dunque un metodo GetMatchingTextRanges(…), il cui compito è di navigare l’intero documento della RichTextBox (un FlowDocument) analizzando esclusivamente gli elementi (inlines) di tipo Run, ovvero quelli che contengono testo.

private List<TextRange> GetMatchingTextRanges(string pattern) 

{ 
   List<TextRange> ranges = new List<TextRange>(); 
  
   TextPointer textNavigator = richTextBox.Document.ContentStart; 
   while (textNavigator.CompareTo(richTextBox.Document.ContentEnd) < 0) 
   { 
      TextPointerContext context = textNavigator.GetPointerContext(LogicalDirection.Backward); 
      if (context == TextPointerContext.ElementStart && textNavigator.Parent is Run) 
      { 
        List<TextRange> runRanges = GetMatchingTextRanges((Run)textNavigator.Parent, pattern); 
        if (runRanges.Count > 0) ranges.AddRange(runRanges); 
      } 

      textNavigator = textNavigator.GetNextContextPosition(LogicalDirection.Forward); 
   } 
  
   return ranges; 
} 

A questo punto, per ogni Run trovato, è possibile controllare se esistono porzioni di testo in esso contenuti che soddisfano il pattern di ricerca. In caso positivo, possiamo aggiungerle alla lista dei TextRange da evidenziare.

private List<TextRange> GetMatchingTextRanges(Run run, string pattern) {             
   List<TextRange> ranges = new List<TextRange>(); 
   MatchCollection matches = Regex.Matches(run.Text, pattern);             
  
   foreach (Match match in matches) 
   { 
     TextPointer startPosition = GetContentTextPointer(run.ContentStart, match.Index - 1); 
     TextPointer endPosition = GetContentTextPointer(run.ContentStart, match.Index + match.Length - 1); 
     ranges.Add(new TextRange(startPosition, endPosition)); 
   } 

   return ranges; 
} 

Come si stabiliscono gli estremi dei TextRange da evidenziare all’interno di ciascun Run? Anzitutto, tramite la classe Regex riusciamo a capire per ciascun match quali sono gli indici dei caratteri iniziali all’interno del testo del Run. Poi, ricordando che per calcolare l’offset corretto all’interno di ciascun Run non dobbiamo considerare i caratteri (un Run può contenere altri tipi di simboli) bensì i TextPointer che sono adiacenti al testo di interesse, definiamo il seguente metodo:

 
private TextPointer GetContentTextPointer(TextPointer contentStart, int offset) 

{ 

  TextPointer result = contentStart; 
  int i = 0; 
  while (i < offset && result != null) 
  { 
    if (result.GetPointerContext(LogicalDirection.Backward) == TextPointerContext.Text || 
        result.GetPointerContext(LogicalDirection.Backward) == TextPointerContext.None) i++; 

    if (result.GetPositionAtOffset(1, LogicalDirection.Forward) == null) return result; 
  
    result = result.GetPositionAtOffset(1, LogicalDirection.Forward); 

  } 

  return result; 

}

Finalmente il gioco è fatto. Di seguito riportiamo un esempio di output ottenuto invocando HilightText(“labor”);

Technorati Tags: WPF,RichTextBox

[WPF] MVVM e Splash Screen

Dario Santarelli — Sun, 30 May 2010 22:36:57 GMT

Durante lo sviluppo di applicazioni WPF di una certa “pesantezza”, può essere utile ricorrere a Splash Screen aggiornabili in tempo reale che notifichino all’utente lo stato di avanzamento del caricamento dei vari moduli, ad esempio tramite elementi di testo piuttosto che barre di progresso. A volte, infatti, può non essere sufficiente una semplice immagine impostabile tramite la Build Action "SplashScreen" di Visual Studio.
In questo post vorrei quindi mostrare una possibile implementazione di uno Splash Screen aggiornabile in tempo reale usando il pattern MVVM.

Per semplificare, supponiamo di posizionare nel Main la pesantissima sequenza di caricamento della nostra applicazione:

public static class Program
{
[STAThread]
public static void Main(string[] args)
{
App app = new App();
app.InitializeComponent(); // Load resources...

    MainWindow mainWindow = null;
    using (SplashScreenViewModel splashScreenViewModel = SplashScreen.ShowSplashScreen())
    {
      splashScreenViewModel.StatusText = "Initializing...";

     // Loading application modules...
      Thread.Sleep(3000); // Simulate delay...

      mainWindow = new MainWindow();

       splashScreenViewModel.StatusText = "Initialized.";
      Thread.Sleep(1000);
   }

app.Run(mainWindow);
}
}

Al fine di evitare fastidiosi effetti di freezing della GUI mentre il thread principale sta caricando i vari pezzi della nostra applicazione, la window dello Splash Screen va fatta girare necessariamente su un thread separato. Al termine della sequenza di caricamento, il thread principale deve poter chiudere lo Splash Screen utilizzando il Dispatcher corretto.
Vediamo quindi il codice della view:

public partial class SplashScreen : Window
{
private static object splashScreenlockObj = new object();

public SplashScreen()
{
InitializeComponent();
DataContext = new SplashScreenViewModel();
}

   public static SplashScreenViewModel ShowSplashScreen()
{
    lock (splashScreenlockObj)
    {
     SplashScreenViewModel splashScreenViewModel = null;
     ManualResetEvent resetEvent = new ManualResetEvent(false);

     Thread splashScreenThread = new Thread(() =>
     {
       Dispatcher.CurrentDispatcher.BeginInvoke((Action)delegate()
       {
         SplashScreen splashScreenWindow = new SplashScreen();
         splashScreenViewModel = (SplashScreenViewModel)splashScreenWindow.DataContext;
         splashScreenViewModel.Dispatcher = Dispatcher.CurrentDispatcher;
         resetEvent.Set();
         splashScreenWindow.Show();
       });
       Dispatcher.Run();

});

              splashScreenThread.SetApartmentState(ApartmentState.STA);
      splashScreenThread.IsBackground = true;
      splashScreenThread.Start();

      resetEvent.WaitOne(); // Wait for viewmodel initialization...

      return splashScreenViewModel;
    }
}
}

Il metodo statico ShowSplashScreen() visualizza lo splash screen e comunica al ViewModel quale Dispatcher utilizzare per la chiusura (InvokeShutdown()).

public class SplashScreenViewModel : ViewModelBase, IDisposable
{
private string _statusText = null;
public string StatusText
{
    get { return _statusText; }
    set
    {
      if (_statusText == value) return;
      _statusText = value;
      OnPropertyChanged("StatusText");
    }
   }

public Dispatcher Dispatcher { get; set; }

public void Dispose()
{
    if (Dispatcher != null)
    {
      Dispatcher.InvokeShutdown();
      Dispatcher = null;
    }
}
}

Technorati Tag: WPF,MVVM

[WPF] Ereditare controlli da classi generiche

Dario Santarelli — Mon, 29 Mar 2010 14:48:27 GMT

In applicazioni WPF di una certa complessità è molto facile trovarsi in situazioni in cui è utile sfruttare classi base per i controlli (es. UserControl e Window). In architetture MVVM, ad esempio, è possibile far ereditare i vari controlli da classi base generiche. Tuttavia, l’ implementazione dell’ereditarietà generica in WPF talvolta non è proprio immediata, soprattutto perché non sempre gli errori di build sono esplicativi.
In questo semplicissimo esempio di MVVM viene mostrato come si può specificare la classe base generica di una Window direttamente nello XAML.

Partiamo dalla Window:

public partial class CustomersWindow : WindowBase<CustomersViewModel>
{
public CustomersWindow() : base(new CustomersViewModel())
{
    InitializeComponent();
}
...
}

La classe base generica della Window potrebbe essere qualcosa del genere...

public class WindowBase<T> : Window where T : ViewModelBase
{
public T ViewModel { get; set; }

public WindowBase() { }

public WindowBase(T viewModel)
{
this.ViewModel = viewModel;
base.DataContext = viewModel;
}
}

Arriviamo quindi al punto. Lo XAML che permette di specificare l’ereditarietà da classi generiche diventa:

<src:WindowBase
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
     xmlns:src="clr-namespace:MyApplication"
     x:Class="MyApplication.CustomersWindow"
     x:TypeArguments="src:CustomersViewModel" ...>
...
</src:WindowBase>

Tramite x:TypeArguments possiamo specificare il tipo generico della classe base.

ATTENZIONE: questa tecnica è applicabile solo per il nodo root del documento XAML.

Technorati Tag: WPF,Generics,Window,Controls

[WPF] Un “generic” command

Dario Santarelli — Sat, 17 Oct 2009 12:41:24 GMT

Analizzando diverse soluzioni WPF che sfruttano l’architettura M-V-VM, mi è saltata all’occhio una strategia di implementazione dell’interfaccia ICommand semplice e potente a mio modo di vedere. Andiamo direttamente al codice:

public class GenericCommand<T> : ICommand
{
public Predicate<T> CanExecuteDelegate { get; set; }
public Action<T> ExecuteDelegate { get; set; }

public bool CanExecute(object parameter)
{
    if (CanExecuteDelegate != null) return CanExecuteDelegate((T)parameter);
    return true;
}

public event EventHandler CanExecuteChanged
{
    add { CommandManager.RequerySuggested += value; }
    remove { CommandManager.RequerySuggested -= value; }
}

public void Execute(object parameter)
{
    if (ExecuteDelegate != null) ExecuteDelegate((T)parameter);
}
}

Sostanzialmente l’obiettivo di questo GenericCommand è di permettere una “tipizzazione” dichiarativa del parametro gestito dall’ interfaccia ICommand, in modo tale da poter costruire ViewModel contenenti delegati che gestiscono il pattern CanExecute/Execute operando a nostro piacimento su parametri tipizzati passati magari direttamente dalla View. Ecco un esempio molto semplice di ViewModel...

public class ContactsViewModel
{
public ObservableCollection<string> Contacts { get; private set; }
public GenericCommand<string> AddContact { get; set; }
public GenericCommand<object> ClearContacts { get; set; }

public ContactsViewModel()
{
    Contacts = new ObservableCollection<string>();
    AddContact = new GenericCommand<string>();
    ClearContacts = new GenericCommand<object>();

    AddContact.CanExecuteDelegate += new Predicate<string>(AddContact_CanExecute);
    AddContact.ExecuteDelegate += new Action<string>(AddContact_Execute);

    ClearContacts.CanExecuteDelegate += new Predicate<object>(ClearContacts_CanExecute);
    ClearContacts.ExecuteDelegate += new Action<object>(ClearContacts_Execute);
}

bool AddContact_CanExecute(string contactName) { return (!string.IsNullOrEmpty(contactName)); }
void AddContact_Execute(string contactName) { Contacts.Add(contactName); }

bool ClearContacts_CanExecute(object parameter) { return (Contacts.Count > 0); }
void ClearContacts_Execute(object parameter) { Contacts.Clear(); }
}

...e per chiudere il cerchio riporto anche lo XAML saliente di una View di esempio.

<TextBox Name="txtContactName" ... />
<Button Command="{Binding AddContact}" CommandParameter="{Binding ElementName=txtContactName, Path=Text}" ...>Add Contact</Button>
<ListBox ItemsSource="{Binding Contacts}" ... />
<Button Command="{Binding ClearContacts}" ...>Clear Contacts</Button>

Cosa ne pensate?

Technorati Tag: WPF,ICommand,M-V-VM

[WPF] Window non rettangolari

Dario Santarelli — Sat, 26 Sep 2009 14:23:09 GMT

La possibilità di creare Window di forma irregolare costituisce a mio modo di vedere uno dei più divertenti nonché semplici vantaggi di WPF.
In genere, ogni tecnica di realizzazione di Window dalla forma completamente personalizzata si basa sulla valorizzazione preliminare di tre proprietà:

In questo modo siamo subito svincolati sia dalla forma rettangolare standard della nostra Window, che dalla barra standard del titolo. Si aprono quindi diverse possibilità di sviluppo. E’ possibile ad esempio sfruttare immagini semitrasparenti come background della Window (scelta semplice e di veloce realizzazione, ma non consigliabile in WPF dal momento che la Window subirebbe un rendering con più pixel in sistemi con maggiori DPIs). Una soluzione sicuramente più potente sfrutta invece il programming model che WPF ci mette a disposizione relativamente alla grafica vettoriale: in altre parole, per creare una Window dai bordi arrotondati basta partire dall’elemento Border.
Vorrei riportare un esempio che mi è rimasto impresso dopo aver letto il libro “Pro WPF in C# 2008” : creare una Window dalla forma irregolare, con bordi arrotondati.
N.B.: tralascio volutamente ogni questione di carattere architetturale ( es. realizzazione di custom control template per le nostre Window ).

Codice XAML:

Code-behind (interaction logic):

public partial class ShapedWindow : Window
{
private bool _isResizing = false;
public ShapedWindow()
{
    InitializeComponent();
    CommandBinding binding = new CommandBinding(ApplicationCommands.Close);
    binding.Executed += CloseWindow;
    this.CommandBindings.Add(binding);
}

private void CloseWindow(object sender, RoutedEventArgs e) { this.Close(); }

private void BeginWindowResize(object sender, MouseButtonEventArgs e) { _isResizing = true; }

private void EndWindowResize(object sender, MouseButtonEventArgs e)
{
    _isResizing = false;
    Rectangle rectangle = (Rectangle)sender;
    rectangle.ReleaseMouseCapture();
}

private void WindowResize(object sender, MouseEventArgs e)
{
    Rectangle rectangle = (Rectangle)sender;
    if (_isResizing)
    {
      rectangle.CaptureMouse();
      double newWidth = e.GetPosition(this).X + 5;
      if (newWidth > 0) this.Width = newWidth;
    }
   }

private void WindowDragMove(object sender, MouseButtonEventArgs e)
{
    if (e.ClickCount == 2) this.WindowState = (this.WindowState == WindowState.Maximized) ? WindowState.Normal : WindowState.Maximized;
    else this.DragMove();
}
}

Si nota subito che in una soluzione di questo tipo (non poteva essere altrimenti) è compito dello sviluppatore gestire sia il resize che il move della Window, dal momento che è assente la barra del titolo standard che l’utente usa comunemente per interagire con la finestra stessa.
Differentemente dal mondo Windows Forms, in WPF è possibile gestire la modalità di dragging della Window semplicemente invocando il metodo Window.DragMove() , che in questo caso specifico viene usato in corrispondenza dell’evento MouseLeftButtonDown scatenato sul TextBlock che funge da barra del titolo ( due click consecutivi invece “massimizzano” o “normalizzano” la finestra ;) ).
Per quanto riguarda invece il resize, la questione diventa un po’ più “complessa”. Anzitutto, impostare la proprietà Window.ResizeMode a CanResizeWithGrip significa far apparire il sizing grip nell’angolo in basso a destra assumendo che la window sia comunque rettangolare. Questo significa quindi che esso può apparire o troppo distante o addirittura sopra l’effettivo bordo della Window.
Se non si vuole scegliere questo tipo di approccio, bensì si desidera poter ridimensionare manualmente la finestra interagendo con i suoi bordi effettivi, esistono due strade: o si utilizzano P/Invoke che inviano messaggi Win32 per ridimensionare la window, oppure più semplicemente (come in questo caso) si gestisce la posizione e l’azione scatenata dal mouse in ogni bordo che si vuole utilizzare per ridimensionare la finestra, andando poi a gestire di conseguenza la proprietà Width.
Nell’esempio, si è scelto di posizionare un Rectangle trasparente di larghezza 5 in corrsipondenza del lato destro della finestra. In questo modo gli opportuni event handler (MouseLeftButtonDown, MouseLeftButtonUp, MouseMove) ci permettono di gestire il resize manuale della window ogni volta che il mouse interagisce con il bordo destro della stessa.

Technorati Tag: WPF

Screenshots di Forms, Windows e schermo

Dario Santarelli — Wed, 09 Sep 2009 00:29:44 GMT

Spesso in ambiente desktop può essere utile salvare degli screenshot relativi alla UI della nostra applicazione: in alcuni scenari ad esempio, oltre ai soliti log e trace, è molto comodo avere automaticamente lo screenshot dell’UI al momento dell’errore, magari come allegato di una email di report.
Una comune soluzione in Windows Forms è quella che sfrutta GDI+ tramite il metodo Graphics.CopyFromScreen(…) . In questo post vorrei mostrare come anche in WPF è possibile approfittare della stessa tecnica con il minimo sforzo: in particolare, nell’ helper class che segue sono presenti degli overload del metodo SaveScreenShot(…) per salvare su file system gli screenshot sia di singole Window (WPF) / Form (Windows Forms) che dell’intero schermo.

public class ScreenshotHelper
{
// Per Windows Forms...
public static void SaveScreenShot(Form form, string fileName, ImageFormat imageFormat)
{
    SaveScreenShot(form.Location, form.Size, fileName, imageFormat);
}

// Per WPF...
public static void SaveScreenShot(Window window, string fileName, ImageFormat imageFormat)
{
    SaveScreenShot(new System.Drawing.Point((int)window.Left, (int)window.Top),
                   new System.Drawing.Size((int)window.Width, (int)window.Height),
                   fileName, imageFormat);
}

private static void SaveScreenShot(System.Drawing.Point windowLocation, System.Drawing.Size windowSize,
                                     string fileName, ImageFormat imageFormat)
{
    using (Bitmap bitmap = new Bitmap(windowSize.Width, windowSize.Height))
    {
      using (Graphics graphics = Graphics.FromImage(bitmap))
      {
        graphics.CopyFromScreen(windowLocation, new System.Drawing.Point(0, 0), windowSize);
      }
      bitmap.Save(fileName, imageFormat);
    }
}

// Schermo intero...
public static void SaveScreenShot(string fileName, ImageFormat imageFormat)
{
     Rectangle bounds = Screen.GetBounds(System.Drawing.Point.Empty);
     using (Bitmap bitmap = new Bitmap(bounds.Width, bounds.Height))
     {
       using (Graphics graphics = Graphics.FromImage(bitmap))
       {
         graphics.CopyFromScreen(System.Drawing.Point.Empty, System.Drawing.Point.Empty, bounds.Size);
       }
       bitmap.Save(fileName, imageFormat);
     }
}
}

Nota: Questo metodo non riesce a catturare controlli trasparenti. Per gestirli occorre utilizzare altri metodi, nativi di GDI+, come mostrato in questo post.

Technorati Tag: WPF,Windows Forms,GDI+