July 2007 - Posts
Su segnalazione di un utente mi sono accorto che nel cd allegato alla rivista ioProgrammo non è stato inserito il codice di esempio utilizzato nel libro su WPF.
E' possibile scaricare il codice qui (circa 2MB).
Con la grossa diffusione di computer portatili diventa sempre più importante sviluppare applicazioni che tengano conto dei consumi e dello stato di alimentazione delle batterie.
Anche con Windows Presentation Foundation, naturalmente, è possibile interagire con i sistemi di notifica di consumo energia per agire di conseguenza con, ad esempio, la disattivazione di animazioni o altre features che comportano un maggiore consumo.
Su MSDN Magazine di Luglio 2007 c'è un interessante articolo che spiega in maniera approfondita come creare applicazioni sensibili al consumo.
Gli argomenti trattati sono:
Creazione di applicazioni che interagiscono con le notifiche di consumo di energia Supporto del risparmio energetico in Windows XP Supporto del risparmio energetico in Windows Vista Proprietà di dipendenza di WPF personalizzate ed eventi indirizzati
Fonte : Make Your Windows Presentation Foundation Applications Power-Aware
| 
| Dopo Petzold, Nathan e Anderson...è in edicola il MIO libro su Windows Presentation Foundation  .
Ebbene si...ne ho scritto uno!  |
| Il titolo è, naturalmente, "Windows Presentation Foundation" e lo trovate in allegato al numero di agosto 2007 di ioProgrammo (n.117). E' stato un lavoro non molto facile visto che ho dovuto parlare di un pò tutto WPF in appena 160 pagine!!! In molti casi quindi non mi è stato possibile scendere nei dettagli ma ho dovuto dare una panoramica generica....e spero di esserci riuscito  . Naturalmente, ogni commento è gradito. Infine, un ringraziamento a chi, quando mi è stata proposta quest'avventura, mi ha incoraggiato a buttarmici . |
Oggi ho avuto la necessità di installare sul mio notebook Reporting Services di SQL Server 2005. Durante la verificare dei requisiti falliva quella relativa alla compatibilità IIS (che mi diceva non essere installato 
) e questo era un problema visto che, senza questo, non avrei potuto installare Reporting.
Verifico l'installazione di IIS e mi accorgo che questo è giò installato sul PC (non avevo dubbi visto che lo utilizzo).
Dunque vediamo...l'ultima volta che ho utilizzato Reporting è stato sul mio vecchio PC dove avevo Windows XP e quindi IIS 6 mentre su Vista viene installato IIS7....vuoi vedere che....
Googlata veloce e capito su un post di Lorenzo Benaglia dove viene spiegata proprio l'installazione di SQL Server 2005 Developer Edition su Vista con in particolare Reporting e IIS7.
Effettivamente, per poter installare Reporting Services con IIS7 occorre selezionare dei particolari componenti di IIS che io non avevo di default come è spiegato in questo post di Brian Welcker.
Selezionati ed installati quei componenti di IIS...l'installazione può proseguire correttamente...
Il .NET Framework supporta un meccanismo chiamato Delayed Signing che permette di firmare l'assembly usando la sola chiave pubblica.
Questo meccanismo può essere molto utile in fase di sviluppo, all'interno di un team, quando non ha senso dare agli sviluppatori la chiave privata per la compilazione e la firma degli assembly.
Così facendo, si da la possibilità sia di referenziare l'assembly con la corretta chiave pubblica (la stessa che verrà utilizzata firmando l'assembly regolarmente), sia di registrare lo stesso nella GAC.
Una chiarissima spiegazione di questo meccanismo la trovate in questo post di Mighell.
Fonte : Delayed Signing
Technorati tags:
GAC,
.NET
In Windows Presentation Foundation è stato introdotto un nuovo controllo molto simile alla classica Label chiamato TextBlock.
Tutti e due i controlli hanno il compito di visualizzare del testo ma ci sono molte differenze tra i due e quindi il controllo TextBlock non va a sostituire la Label.
Innanzitutto TextBlock NON è un controllo! Anche se questo è contenuto nel namespace System.Windows.Controls, deriva direttamente da FrameworkElement e non da ContentControl come la Label.
Altre differenze sono:
- Label supporta gli "Access Key", TextBlock NO.
- Quando una Label viene disabilitata, questa assume un aspetto grigio mentre nel TextBlock questo comportamento non è implementato di default.
- TextBlock supporta funzionalità avanzate di formattazione del testo permettendo anche la creazione di paragrafi.
In questo post di Josh Smith vengo analizzata nel dettaglio le differenze principali tra i due oggetti, molto utile per schiarirsi le idee.
Fonte : Differences between Label and TextBlock
Qualcuno ha avuto il coraggio di nominarmi Vice-Presidente di DotNetSide...così è partita la mia campagna elettorale per la scalata al potere.
Technorati tags:
DOtNetSide,
Community
In Windows Presentation Foundation è possibile utilizzare controlli Windows Forms.
Supponiamo di voler utilizzare il controllo ReportViewer di Reporting Services in un'applicazione WPF.
Innantitutto, per poter "hostare" (...e qualcuno dopo questo termine mi bloccherà tra i suoi contatti ) controlli Windows Forms, occorre referenziare due dll nella nostra applicazione WPF: System.Windows.Forms.dll e WindowsFormsIntegration.dll.
Fatto questo occorre, se necessario, referenziare la/le dll necessarie all'utilizzo del controllo Windows Forms che vogliamo utilizzare. In questo caso Microsoft.ReportViewer.Common.dll e Microsoft.ReportViewer.WinForms.dll.
Naturalmente, andremo ad aggiungere nel codice XAML, il namespace che contiene il controllo ReportViewer:
<Window x:Class="WindowsFormsHostSample.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:viewer="clr-namespace:Microsoft.Reporting.WinForms;assembly=Microsoft.ReportViewer.WinForms"
Title="Test WindowsFormsHost" Height="600" Width="900"
Loaded="Window_Loaded"
>
<Grid x:Name="main">
</Grid>
</Window>
A questo punto possiamo posizionare all'interno di una Window e, per fare questo basta utilizzare un WindowsFormsHost, un elemento che permette, appunto, di contenere un controllo Windows Forms in una Window/Page WPF.
<WindowsFormsHost>
<viewer:ReportViewer />
</WindowsFormsHost>
Ecco fatto.
Naturalmente, è possibile aggiungere un controllo Windows Forms anche da codice:
private void Window_Loaded(object sender, RoutedEventArgs e)
{
System.Windows.Forms.Integration.WindowsFormsHost host =
new System.Windows.Forms.Integration.WindowsFormsHost();
Microsoft.Reporting.WinForms.ReportViewer viewer =
new Microsoft.Reporting.WinForms.ReportViewer();
host.Child = viewer;
main.Children.Add(host);
}
Un paio di "cosette" che mi sento di segnalare:
- E' preferibile utilizzare questa tecnica solo nei casi in cui abbiamo, ad esempio, un nostro UserControl già sviluppato in WindowsForms e non abbiamo tempo o comunque possibilità per riscriverlo in WPF o nei casi estremi in cui non abbiamo un alternativa del controllo in WPF (come nel caso del ReportViewer che personalmente non ho trovato)
- Anche se WindowsFormsHost può essere utilizzato in qualsiasi Window WPF, questo non supporta importanti funzionalità del nuovo engine come animazioni, trasformazioni e, soprattutto, rendering vettoriale.
Il databinding in Windows Presentation Foundation è sicuramente una delle potenzialità maggiori introdotte dal nuovo engine. In situazioni di binding in cui abbiamo la necessità di formattare il valore da visualizzare in un controllo sono utilissimi i ValueConverter. Questi ci permettono, appunto, di modificare il valore da visualizzare nel controllo "target" del binding.
Per creare un nostro ValueConverter occorro, innanzitutto, creare una classe che implementi l'interfaccia IValueConverter e, naturalmente, i due metodi necessari Convert e ConvertBack.
Supponiamo di voler creare un ValueConverter per la formattazione di date. Implementiamo, innanzitutto, la classe DateConverter e il metodo Convert che, semplicemente, restituisce una data formattata.
public class DateConverter : IValueConverter
{
public object Convert(object o, Type type, object parameter, CultureInfo culture)
{
DateTime date = (DateTime)o;
switch (type.Name)
{
case "String":
//return date.ToString( "F", culture);
return date.ToString("dddd dd/MM/yyyy", culture);
default:
return o;
}
}
public object ConvertBack(object o, Type type, object parameter, CultureInfo culture)
{
//return null;
throw new NotSupportedException();
}
}
A questo punto possiamo utilizzare il nuovo ValueConverter creato in qualsiasi operazione di binding definendolo a livello di Resource e, nella markup extension Binding attraverso la proprietà Converter:
<Window.Resources>
<local:DateConverter x:Key="myDateConverter"/>
</Window.Resources>
.....
<TextBlock Text="{Binding Path=DataNascita, Converter={StaticResource myDateConverter}}" />
Il metodo ConvertBack, che nell'esempio non è implementato, serve per, appunto, l'operazione inversa per riportare quindi la data nel suo formato originale.
I alcuni casi, in applicazioni WPF, si possono verificare evidenti rallentamenti e spesso succede quando l'applicazione gira su Windows XP o Windows Server 2003 e la proprietà Windows.AllowsTransparency viene impostata a True.
Ecco qui un hotfix che risolve questa situazione: http://support.microsoft.com/kb/937106/en-us