Piccolo quiz: Cosa c’è che non va nel codice che vedete qui sotto? (5 secondi per rispondere…)
1: private void Button_Click(object sender, System.Windows.RoutedEventArgs e)
2: {
3: SaveFileDialog sfd = new SaveFileDialog();
4: sfd.Filter = "All Files (*.*)|*.*|Text Files (*.txt)|*.txt";
5: sfd.FilterIndex = 2;
6: bool? ret = sfd.ShowDialog();
7: if ((bool)ret)
8: {
9: Stream stream = sfd.OpenFile();
10: using (StreamWriter sw = new StreamWriter(stream))
11: {
12: sw.WriteLine(txtText.Text);
13: }
14: }
15: }
Risposta: Nulla! funziona benissimo.
E’ un banale esempio d’uso della nuova classe SaveFileDialog la quale permette di salvare un file sulla macchina locale da un applicazione Silverlight3, notare come, nemmeno sotto tortura , è possibile risalire al percorso completo del file, quello che viene messo a disposizione è esclusivamente uno stream all’interno del quale è possibile scrivere.
Provando questo esempio di codice, ho capito perchè nella realtà IT Italiana il debugger viene visto come un entità astratta della quale si è sentito parlare ma che è meglio non usare: Perchè in questo caso usare il debugger fa male!
Mettete un breakpoint in una qualsiasi delle righe prima della chiamata a ShowDialog e premete F10 eseguendo le istruzioni passo a passo, arrivati alla ShowDialog ecco cosa succede:
Una “Dialogs must be user-initiated” exception.
Visto che in realtà questo problema mi dicono sia da tempo presente anche in Silverlight2 (nella OpenFileDialog, non ho comunque verificato…) qualcosa mi dice che sarà presente anche in RTM.
Per carità, nulla di preoccupante, ma anche in questo caso, DEV avvisato…