WPF

[WPF] Un “generic” command

Dario Santarelli — Sat, 17 Oct 2009 09: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 11: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 — Tue, 08 Sep 2009 21: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+

[WPF] Application Shutdown

Dario Santarelli — Wed, 26 Aug 2009 12:08:06 GMT

In un’ applicazione WPF, per default la classe Application mantiene viva l’applicazione stessa finché almeno una finestra è ancora aperta. Se si vuole cambiare questo comportamento, è possibile utilizzare la proprietà Application.ShutdownMode direttamente dal markup XAML:
( ATTENZIONE: se si istanzia l’oggetto Application a mano, è obbligatorio impostare la proprietà ShutdownMode prima di invocare il metodo Run() )

I valori ammissibili per tale proprietà sono:

OnLastWindowClose (default): l’applicazione WPF rimane in vita fintantoché esiste almeno una Window attiva. Se si chiude la MainWindow, la proprietà Application.MainWindow continua a puntare alla MainWindow chiusa. In questo tipo di situazione, si può quindi scegliere di ri-assegnare da codice la proprietà MainWindow in modo tale che essa punti ad una Window differente.
OnMainWindowClose: l’applicazione WPF rimane viva fintantoché la MainWindow è aperta.
OnExplicitShutdown: L’applicazione WPF rimane viva fintantoché non viene chiamato esplicitamente il metodo Application.Shutdown(), anche se tutte le Window sono chiuse. E’ chiaro che questo approccio ha senso nel caso in cui occorra gestire una logica complessa per stabilire se e quando la nostra applicazione debba chiudersi.

Un paio di note:

Indipendentemente dal meccanismo di shutdown scelto, il metodo Application.Shutdown() è sempre valido per iniziare il processo di terminazione dell’applicazione: dietro le quinte, infatti, il metodo Application.Shutdown() non fa altro che scatenare l’uscita dal metodo Application.Run(), il che (occhio!) non preserva dall’esecuzione di eventuale codice aggiuntivo nel Main() o nel gestore dell’evento Application.Exit.
Quando ShutdownMode=”OnMainWindowClose” e viene chiusa la MainWindow, l’oggetto Application chiude automaticamente tutte le altre finestre prima che il contesto di esecuzione esca dal metodo Run(), analogamente a quanto avviene invocando il metodo Application.Shutdown().

Technorati Tag: WPF,Shutdown

[WPF] ICommand e CanExecute

Dario Santarelli — Thu, 02 Apr 2009 18:18:39 GMT

Per chi sviluppa utilizzando il pattern M-V-VM l’interfaccia ICommand costituisce la base per costruire un’infrastruttura che permetta alla View di invocare comandi applicativi direttamente nel ViewModel. L’interfaccia mette a disposizione tre semplici membri: due metodi Execute(...), CanExecute(...) ed un evento CanExecuteChanged. E’ facile immaginare come in progetti di una certa consistenza sia necessario costruirsi delle implementazioni spesso particolari dell’interfaccia ICommand, cosa che da una parte implica tanta buona volontà, dall’altra ripaga quando si dormono sonni tranquilli pensando ad una View completamente svincolata dalla logica applicativa.
In genere un’ utile implementazione di ICommand poggia sull’ intercettazione dell’evento CanExecuteChanged in modo da poter esporre alla View informazioni sul fatto che il nostro command sia o meno eseguibile ( si pensi ad esempio ad un Button enabled o meno ). A mio modo di vedere, una limitazione dell’interfaccia ICommand risiede nel metodo CanExecute(…) , il quale appunto è un metodo ( con annesso parametro opzionale ) e non una proprietà, cosa che non mette a disposizione il classico pattern Property/PropertyChanged sfruttabile nei data binding tra ViewModel e View.
E’ semplice ovviare a questa situazione: ad esempio si può fare in modo che il nostro ICommand implementi una sorta di proprietà “wrapper” per esporre un sistema binding-friendly CanExecute/CanExecuteChanged.
Vediamo un esempio pratico. In una mia applicazione WPF avevo bisogno di realizzare un VM per una Window di Login e volevo “bindare” la proprietà CanLogin del VM ( che semplicemente ritorna true se UserName e Password sono entrambi valorizzati ) direttamente con il metodo CanExecute(…) del mio ICommand.

Ho quindi realizzato un’implementazione di ICommand (chiamata senza fantasia CanExecuteCommand) che accetta:

Un Delegate da eseguire all’interno dell’ Execute(…)
Un oggetto di tipo Binding che rappresenta il binding tra una proprietà “wrapper” per il metodo CanExecute(…) dell’ ICommand (nello specifico CanExecuteAction) e una proprietà del ViewModel (nello specifico CanLogin) in modo da poter scatenare l’evento CanExecuteChanged proprio al variare della proprietà CanLogin del ViewModel.

Difficile da spiegare, facile da implementare :D

Command:

public class CanExecuteCommand : DependencyObject, ICommand
{
   Action<object> _executeDelegate;
   public event EventHandler CanExecuteChanged;

   public bool CanExecuteAction
   {
     get { return (bool)GetValue(CanExecuteActionProperty); }
     set { SetValue(CanExecuteActionProperty, value); }
   }

   public static readonly DependencyProperty CanExecuteActionProperty =
          DependencyProperty.Register("CanExecuteAction", typeof(bool), typeof(CanExecuteCommand),
                                      new PropertyMetadata(OnCanExecuteActionChanged));

   public CanExecuteCommand(Action<object> executeDelegate) : this(executeDelegate, null) { }

   public CanExecuteCommand(Action<object> executeDelegate, Binding canExecuteActionBinding)
   {
      _executeDelegate = executeDelegate;
      if (canExecuteActionBinding != null) BindingOperations.SetBinding(this, CanExecuteActionProperty, canExecuteActionBinding);
   }

   #region ICommand Members

   public void Execute(object parameter) { _executeDelegate(parameter); }

   public bool CanExecute(object parameter) { return CanExecuteAction; }

   #endregion

   private void RaiseCanExecuteActionChanged()
   {
     if (CanExecuteChanged != null) CanExecuteChanged(this, new EventArgs());
   }

   static void OnCanExecuteActionChanged(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs args)
   {
    (dependencyObject as CanExecuteCommand).RaiseCanExecuteActionChanged();
   }
}

ViewModel:

public class LoginViewModel : ILoginViewModel, INotifyPropertyChanged
{
private string _username;
private string _password;

public event PropertyChangedEventHandler PropertyChanged;

public ICommand ReadyCommand { get; private set; } // In Binding con la View

#region ILoginViewModel Members

public string UserName // In Binding con la View
{
    get { return _username; }
    set
    {
      if (_username != value)
      {
        _username = value;
        RaisePropertyChanged("UserName");
        RaisePropertyChanged("CanLogin");
      }
    }
}

public string Password // In Binding con la View
{
    get { return _password; }
    set
    {
      if (_password != value)
      {
        _password = value;
        RaisePropertyChanged("Password");
        RaisePropertyChanged("CanLogin");
      }
     }
   }

public bool CanLogin
{
    get { return !string.IsNullOrEmpty(UserName) && !string.IsNullOrEmpty(Password); }
}

public void Login()
{
    //... Do Login...
}

#endregion

public LoginViewModel()
{
    Binding binding = new Binding("CanLogin");
    binding.Source = this;
    ReadyCommand = new CanExecuteCommand((arg) => Login(), binding);
}

private void RaisePropertyChanged(string propertyName)
{
   if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}

Technorati Tag: WPF,ICommand

[Silverlight/WPF] Resource file e Access Modifier

Dario Santarelli — Thu, 19 Mar 2009 22:02:41 GMT

Più volte nello sviluppo Silverlight/WPF mi sono imbattuto nella necessità di utilizzare i file di risorsa (.resx) e devo dire che le prime volte mi sono trovato un po’ in difficoltà dal momento che non riuscivo a capire per quale arcano i miei binding dichiarativi nel codice XAML verso le mie risorse non funzionassero affatto. Andiamo per ordine: supponendo di definire un file di risorsa in questo modo ...

... in fase di design Visual Studio notifica uno “strano” errore,

indipendentemente dal fatto che si utilizzi Public o Internal come access modifier (più precisamente se si selezionasse Internal l’errore diverrebbe AG_E_PARSER_BAD_TYPE). Mantenendo l’access modifier come “Public” ed andando a vedere il codice autogenerato da Visual Studio ci si imbatte in questa piccola “finezza”:

Classe public e costruttore internal!!!

Personalmente ho sempre ovviato al problema nel modo più semplice, impostando il costruttore come public per ogni file di risorsa. Oggi invece mi imbatto in questo post che propone invece una soluzione più elegante a cui non avevo proprio pensato, ovvero realizzare semplicemente una classe pubblica con una singola proprietà che espone la classe associata al file di risorsa. SEMPLICE MA GENIALE!!!

Technorati Tag: Silverlight 2,WPF

Da WindowsForms a WPF via MVP

Dario Santarelli — Fri, 27 Feb 2009 18:43:19 GMT

Qualche giorno fa mi sono imbattutto in una simpatica applicazione Windows Forms che permette di disegnare su una lavangna virtuale il posizionamento in campo di due squadre di calcio. Un'applicazione per allenatori insomma :D. In breve, il funzionamento è semplicemente basato sull'aggiunta e sullo spostamento di pedine (rosse o blu) su un campo di calcio virtuale con eventuale possibilità di ingrandirne/rimpicciolirne le dimensioni.
Guardando il sorgente ho osservato come l’intera applicazione fosse stata concepita e sviluppata "alla Windows Forms" con l'intera logica piazzata all'interno di ciascun event handler dei vari elementi dell'UI.
Ho quindi pensato di esercitarmi nel fare un po' di refactoring, ma soprattutto di analizzare alcuni aspetti prettamente grafici nel porting di una applicazione WindowsForms ad una versione WPF.
Dal punto di vista architetturale, prima di passare alla versione MVVM ho anzitutto ritenuto opportuno inserire un “passaggio intermedio” nel refactoring, soffermandomi su una versione MVP. Il tutto per mettere sostanzialmente in risalto al mio cervello i principali punti di differenza tra i due pattern. Inoltre, come già accennato, la fase di analisi ha toccato alcune potenzialità grafiche di WPF, come il Drag & Drop/Move e lo Zoom.

In questo post vorrei condividere con voi come mi sono mosso, sperando di ricevere magari qualche utile consiglio ;D

Anzitutto sono partito definendo un mini-core, ovvero un'interfaccia "marker" IView per le View

public interface IView { }

ed una classe generica astratta per il presenter:

public abstract class PresenterBase<T> where T : IView
{
public T View { get; set; }
}

A questo punto ho iniziato il porting della Form principale dell'applicazione di partenza (che si chiamava SoccerBlackBoardForm) realizzando la corrispondente Window WPF (SoccerBlackBoardWindow) che implementa un'interfaccia IBlackboardView dedotta analizzando il codice dell'applicazione originale. Infine ho realizzato una classe presenter BlackboardPresenter per le View che implementano IBlackboardView. Il tutto è rappresentato sinteticamente nel seguente class Diagram:

Omettendo per brevità il codice dell'interfaccia IBlackboardView, riporto direttamente lo scheletro del mio refactoring dal momento che si tratta di codice abbastanza autoesplicativo:

1. La costruzione della Window SoccerBlackBoardWindow ha letteralmente svuotato di logica la corrispondente versione Windows Forms fino ad avere la seguente forma:

SoccerBlackBoardWindow.xaml

<Grid>

<Grid.ColumnDefinitions>

</Grid.ColumnDefinitions>

<ListBox.ItemTemplate>

</DataTemplate>

</ListBox.ItemTemplate>

</ListBox>

<Button Content="Add Image >>" Click="AddImageClick" ...></Button>

</StackPanel>

<Canvas.Background>

</Canvas.Background>

</Canvas>

</Grid>

</Window>

SoccerBlackBoardWindow.xaml.cs

public partial class SoccerBlackBoardWindow : Window, IBlackboardView
{
private BlackboardPresenter _presenter;

#region IBlackboardView Members

public Panel DrawingArea
{
    get { return drawingArea; }
}

public Point MousePosition
{
    get { return Mouse.GetPosition(drawingArea); }
}

public IList<BitmapSource> AvailableImages
{
    get { return (IList<BitmapSource>)lstImages.ItemsSource; }
    set { lstImages.ItemsSource = value; }
}

public BitmapSource SelectedImage
{
    get { return (BitmapSource)lstImages.SelectedItem; }
    set { lstImages.SelectedItem = value; }
}

public void AttachPresenter(BlackboardPresenter presenter) { _presenter = presenter; }

#endregion

public SoccerBlackBoardWindow()

{

InitializeComponent();

_presenter = new BlackboardPresenter(this);

_presenter.LoadImages();
}

protected void AddImageClick(object sender, RoutedEventArgs e) { _presenter.DrawImage(SelectedImage, new Size(100, 100), 0, 0, 0); }

protected void ClearClick(object sender, RoutedEventArgs e) { _presenter.ClearDrawingArea(); }

}

2. Il presenter BlackboardPresenter è stato quindi realizzato per aggiornare la View sia in base agli eventi utente e l'interazione con il model, che in questo caso è dato da una banale collezione readonly di immagini che l'utente ha a disposizione per l'inserimento nella area di disegno (DrawingArea)
Notare come sia semplice realizzare un meccanismo di Drag & Move :D.

BlackboardPresenter.cs

public class BlackboardPresenter : PresenterBase<IBlackboardView>
{
private Point _tmpPosition;
private const int ZOOMDELTA = 10;

public BlackboardPresenter(IBlackboardView view) { View = view; }

public void LoadImages()
{
    IList<BitmapSource> availableImages = new List<BitmapSource>();
    availableImages.Add(new BitmapImage(new Uri("Resources/SoccerBall.png", UriKind.Relative)));
    availableImages.Add(new BitmapImage(new Uri("Resources/blueBall.png", UriKind.Relative)));
    availableImages.Add(new BitmapImage(new Uri("Resources/redBall.png", UriKind.Relative)));
    View.AvailableImages = availableImages;
}

public void ClearDrawingArea(){ View.DrawingArea.Children.Clear(); }

public Image DrawImage(ImageSource source, Size size, int canvasLeft, int canvasTop,int zIndex)

{

Image image = new Image();

image.Source = source;

image.Height = size.Height;

image.Width = size.Width;

image.Cursor = Cursors.Hand;

Canvas.SetLeft(image, canvasLeft);

Canvas.SetTop(image, canvasTop);

Panel.SetZIndex(image, zIndex);

image.MouseMove += delegate(object o, MouseEventArgs args) { MoveImage(image); };

image.MouseWheel += delegate(object o, MouseWheelEventArgs args) { ZoomImage(image, args.Delta); };

image.MouseDown += delegate(object o, MouseButtonEventArgs args) { CaptureImage(image); };

image.MouseUp += delegate(object o, MouseButtonEventArgs args) { ReleaseImage(image); };

View.DrawingArea.Children.Add(image);

return image;

}

public void ReleaseImage(Image image) { image.ReleaseMouseCapture(); }

public void CaptureImage(Image image)

{

image.CaptureMouse();

_tmpPosition= View.MousePosition;

}

public void MoveImage(Image image)

{

if (Mouse.LeftButton == MouseButtonState.Pressed)

{

Canvas.SetLeft(image, Canvas.GetLeft(image) + (View.MousePosition.X - _tmpPosition.X));

Canvas.SetTop(image, Canvas.GetTop(image) + (View.MousePosition.Y - _tmpPosition.Y));

}

_tmpPosition= View.MousePosition;

}

public void ZoomImage(Image image, int amount)

{

if (amount > 0)

{

image.Height += ZOOMDELTA;

image.Width += ZOOMDELTA;

}

else

{

if ((image.Height - ZOOMDELTA > ZOOMDELTA) && (image.Width - ZOOMDELTA > ZOOMDELTA))

{

image.Height -= ZOOMDELTA;

image.Width -= ZOOMDELTA;

}

Il risultato ottenuto è raffigurato qua sotto: non vi dico quanto è stato divertente usare questa app per spiegare alla mia compagna la tattica del fuorigioco :D.

Technorati Tag: MVP, WPF

[WPF] Creare un ColorPicker

Dario Santarelli — Fri, 05 Dec 2008 18:59:32 GMT

In generale, una semplice soluzione per realizzare un ColorPicker si basa sull'utilizzo di un' immagine che rappresenta lo spettro dei colori, come la seguente:

Dopodiché, per rilevare il colore selezionato al passaggio del Mouse abbiamo ovviamente bisogno di conoscere le coordinate del cursore su tale immagine.

In WPF questa operazione è veramente molto semplice sfruttando la classe CroppedBitmap.
Se definissimo una BitmapSource come Source della nostra Image WPF, ecco come potremmo implementare un semplice metodo per individuare il colore RGB corrispondente alle coordinate del cursore (MouseX,MouseY) su tale immagine-spettro:

using System.Windows.Media.Imaging;

...

public System.Windows.Media.Color GetSelectedColor(BitmapSource bitmapSource, int MouseX, int MouseY)
{
CroppedBitmap cb = new CroppedBitmap(bitmapSource, new Int32Rect(MouseX, MouseY, 1, 1)); // CroppedBitmap di 1px X 1px
rgbChannels = new byte[4];
cb.CopyPixels(rgbChannels, 4, 0); // 4 è la dimensione minima specificabile per individuare il colore RGB
return System.Windows.Media.Color.FromRgb(rgbChannels[2], rgbChannels[1], rgbChannels[0]); // R,G,B
}

Un esempio di Colorpicker WPF stupidissimo sviluppato con questa tecnica potebbe essere il seguente:

P.S.: Se la nostra Bitmap provenisse dal mondo GDI+ ( System.Drawing.Bitmap ), avremmo bisogno di una conversione in BitmapSource (WPF). A riguardo, riporto un metodo che effettua tale conversione tramite il BREVISSIMO metodo CreateBitmapSourceFromHBitmap di System.Windows.Interop.Imaging:

private BitmapSource GetBitmapSource(System.Drawing.Bitmap source)
{
return System.Windows.Interop.Imaging.CreateBitmapSourceFromHBitmap(source.GetHbitmap(),IntPtr.Zero,Int32Rect.Empty,
System.Windows.Media.Imaging.BitmapSizeOptions.FromEmptyOptions());
}

Technorati Tag: WPF

[WPF] PropertyGrid su CodePlex

Dario Santarelli — Wed, 03 Dec 2008 08:37:38 GMT

Stavo cercando un controllo PropertyGrid per WPF ed in men che non si dica ecco che esce fuori su codeplex:

WPF PropertyGrid Control

Forte!!!
Come si può notare è molto simile al property editor di Expression Blend, anche se lo scopo del progetto è:

The purpose of this project not to clone existing Microsoft Expression Blend property editor or Visual Studio 2008 property pad for "Cider" WPF designer but rather introducing a scalable and comprehensive control ready to be used in different types of applications

Credo sarà interessante dare un'occhiata al sorgente :D

P.S.: Se qualcuno di voi già lo conosce/utilizza mi piacerebbe avere qualche feedback giusto per valutarne le potenzialità.

Technorati Tag: WPF,PropertyGrid

[WPF] Considerazioni su M-V-VM

Dario Santarelli — Sun, 30 Nov 2008 15:22:13 GMT

In questi giorni sto studiando a fondo il pattern M-V-VM ((Data)Model-View-ViewModel), visto che quando fu introdotto per la prima volta (ormai 3 anni fa) non lo valutai affatto positivamente poiché ero convinto che avrebbe "sporcato" troppo il pattern MVC, creando confusione sia tra gli sviluppatori che tra gli architects.
Questo pattern fu coniato nel 2005 da John Gossman mentre WPF vedeva la luce (Avalon). In uno dei suoi post a riguardo, Gossman lo definì nella seguente maniera:

Model/View/ViewModel is a variation of Model/View/Controller (MVC) that is tailored for modern UI development platforms where the View is the responsibility of a designer rather than a classic developer....The Model is defined as in MVC...The View consists of the visual elements... The ViewModel can be thought of as abstraction of the view, but it also provides a specialization of the Model that the View can use for data-binding. In this latter role the ViewModel contains data-transformers that convert Model types into View types, and it contains Commands the View can use to interact with the Model.

A seguito di un'analisi più attenta, devo dire che ho modificato la mia posizione iniziale, soprattutto considerando che in linea teorica il pattern M-V-VM può essere utilizzato congiuntamente al pattern MVC ( MVC + VM ). D'altronde, il fatto che si possieda o meno un ViewModel è ortogonale al fatto che si possieda o meno un Controller.
Il ViewModel infatti può assumere due ruoli:

un livello di astrazione per la View
una specializzazione del (Data)Model che la View utilizza per il DataBinding (tramite una trasformazione dei tipi del Model nei tipi della View) e che contiene i Commands che la View può usare per interagire con il Model

Da una parte, gli aspetti che mi piacciono di questo pattern architetturale sono quelli che lo rendono più vicino ad un "WPF-friendly wrapper" del pattern MVC:

supporto totale al two-way databinding offerto da WPF (dati da-verso la View)
maggiore semplificazione/flessibilità dello sviluppo di un' applicazione WPF di qualità (SoC) rispetto a soluzioni MVP (già affermate in particolar modo su Windows Forms e ASP.NET) o MVC (ragazzi ASP.NET MVC è perennemente in Beta :D !!!).

...Dall'altra mi ritrovo a riflettere su alcuni punti critici di tale pattern che potrebbero minacciare seriamente lo sviluppo di applicazioni enterprise:

In scenari complessi potrebbe essere estremamente difficile progettare un ViewModel che risponda al giusto livello di generalità (ricordiamoci che il ViewModel ingloba Proprietà, Astrazioni del DataModel (ObservableCollection), una sfilza di ICommand, Change Notification via INotifyPropertyChanged etc..)
Il miracoloso meccanismo dichiarativo di DataBinding non è facile da debuggare quanto il classico approccio imperativo. E' anche vero che una semplice scappatoia per difficoltà di questo tipo rimane pur sempre l'intercettazione degli eventi che ci servono sia lato View che lato ViewModel.
Poiché un DataBinding dietro le quinte alloca delle risorse di "book-keeping" (contabilità :D), se si implementano pesanti scenari di MultiBinding (in cui uno stesso oggetto è associato a più componenti dell'UI) si possono ottenere situazioni in cui i Binding sono addirittura più pesanti degli oggetti bindati!!! E' sicuramente difficile che si presenti un caso di questo tipo in un' applicazione reale, ciò non toglie che un occhio alle performance dovremmo sempre darglielo.

In questo post di Karl Shifflett ho trovato interessante questa immagine che evidenzia tutte le caratteristiche di un' architettura M-V-VM in un contesto LOB. I concetti ci sono praticamente tutti... ora sta a noi portarli in vita :D

Technorati Tag: WPF,M-V-VM