Windows Azure
Programmare per il Cloud Computing
di Fabio Cozzolino
Ediz. FAG

Il Cloud Computing targato Microsoft è dietro l’angolo? Sarà facile, oltre che conveniente, creare nuove applicazioni su tale nuvola o riciclarne di preesistenti, possibilmente ri-usando codice che abbiamo sudato a creare e collaudare? A tutte queste domande dà un significativo contributo il manuale suddetto, in termini architetturali e pratici, con abbondanza di esempi validi:

Approfittando dell’opera, in questo articolo mi propongo di focalizzare un aspetto non secondario di Azure, ovvero la prima delle seguenti due modalità che la piattaforma offre per la gestione di dati “classici”:

• Table Storage, che a sua volta fa parte di un insieme di servizi, gli Azure Storage Services
• Azure Sql

Tale scelta è giustificata in primo luogo dall’intenzione di limitarsi a fornire un’idea iniziale sul nuovo mondo, ma soprattutto per il fatto che Azure Sql è sostanzialmente conforme a Windows Sql Server 2008, mentre Table Storage ha connotati del tutto diversi e più affini all’ambiente Cloud, pertanto uno sguardo ad esso consente di farsene meglio una prima idea.

MANI AVANTI: DESUMO QUESTE NOTE DAL TESTO SUCCITATO MA NON AVENDO PROVATO AZURE NON ESCLUDO INESATTEZZE E OPINIONI DISCUTIBILI. OGNI RILIEVO O CRITICA SARA' COMUNQUE BEN ACCETTA:

Come viene ben richiamato nel primo capitolo, la Windows Azure Platform è un cloud pubblico di tipo PaaS (Platform as a Service) che cioè non si limita a offrire un’infrastruttura – su cui peraltro Microsoft ha pesantemente investito con una gran quantità di superserver dislocati nel pianeta – ma un completo sistema operativo” virtualizzato” arricchito di molte funzionalità built-in, per gestire le quali l’utente di Azure (ma sarebbe meglio chiamarlo abbonato, anzi in Inglese si parla di “tenant”, affittuario) non deve minimamente preoccuparsi. Di questi caratteri del paradigma Cloud e di Azure stesso ormai si straparla su tutte le gazzette informatiche e sul web, pertanto qui li do per noti, ricordando solo tre punti rilevanti:

• L’SDK fornito agli utenti Azure comprende un completo sistema di debug e sviluppo fruibile in locale, con un’interfaccia simile a quella cui i programmatori .NET sono avvezzi; una bella comodità anche se i risultati testati vanno poi adattati al Cloud a causa di qualche differenza fra ambiente locale, emulato, e ambiente reale su cui pubblicare le nostre applicazioni;
• Nel mondo Azure non si parla più di File System, ma di indirizzi internet, di qui una particolare sintassi (la cui trattazione sistematica non è oggetto di questo intervento, che però comunque ne fornisce spunti, spero, significativi);
• Azure è decisamente aderente alla filosofia SOA (Software As a Service), come già si comprende dagli Storage Services citati sopra.

Una tipica sessione con Azure Table Storage

I servizi Azure Storage Services comprendono a loro volta un modulo Table Storage Services più un secondo dedicato agli oggetti multimediali (blob, binary large object) e altri due per la gestione delle cosiddette queue (code) e dei drive. In questa anteprima diamo un’occhiata solo ai primi.

Una tabella gestita coi Table Storage Services è formata da colonne (campi) e righe (record) ma non aderisce alle norme SQL come magari ci si attende, tant’è vero che questo sistema database viene esplicitamente catalogata come NoSQL (più chiaro di così...). Quindi, se per un verso questo dato di fatto ci libera dai “constraints” e dalle sottili regole dei database SQL veraci, per contro ci impone una totale responsabilità sulle modalità di elaborazione. In particolare ciò vale per le operazioni di join fra tabelle correlate, com’è da attendersi, ma rende problematiche anche quelle di ordinamento, come forse non tutti si aspettavano. La definizione stessa delle tabelle Azure ne viene influenzata (per esempio, creandone con molti più campi, con ridondanze più o meno inevitabili... beninteso è un’impressione a caldo).

La situazione che sto per esaminare, sintetizzando gli esempi del bravo Cozzolino, discende in sostanza da due fattori:

• ·         L’architettura SOA, service oriented che è a fondamento di Azure (in pratica è del tutto simile ai WCF Data Services, ove WCF è Windows Comunication Foudation, comunque i brani riportati si lasciano comprendere o, perlomeno, intuire);
• ·         La necessità di ottenere la massima scalabilità ed efficienza in un ambiente Cloud, ove i dati possono trovarsi (si perdoni l’espressione pittoresca) “spezzettati”, “sparpagliati” su macchine virtuali (VM) dislocate negli innumerevoli server che Microsoft mette a disposizione per la piattaforma Azure; in buona sostanza inoltre ciò significa che una tabella del genere potrebbe, nel tempo, essere spostata e trovarsi suddivisa su VM diversi.

Nota. Questa situazione, di primo acchito un po’ sconcertante, accomuna gran parte se non tutte le piattaforme Cloud, allo scopo di massimizzare l’occupazione. Ma non potrebbero derivarne tempi di risposta eccessivi? Il dubbio esiste, comunque Azure li riduce con tecniche di query simultanee, inoltre permette ai propri abbonati di delimitare le aree geografiche (evitando putacaso che i dati di un italiano finiscano in India...).

Ma entriamo in medias res con un esempio tipico, relativo a un oggetto Prodotto che si definisce tramite una classe dotata di proprietà che corrispondono ai campi di una omonima tabella, più altri tre campi a sorpresa - PartitionKey, RowKey e TimeStamp - obbligatori e di nome predefinito:

[DataServiceKey ("PartitionKey", "RowKey"]

Public Class Prodotto

{

    Public String PartitionKey { get; set }

    Public String RowKey { get; set }

    Public DateTime TimeStamp { get; set }

    Public String NomeProd { get; set }

    Public Double Prezzo { get; set }

    Public Int Giacenza { get; set }

    Public Int ScortaMin { get; set }

}

La prima riga entro parentesi quadre è una tipica direttiva rivolta ai Table Storage Services che caratterizza la tabella secondo le due chiavi dette, la prima che fissa la partizione, la seconda che serve a individuare univocamente ciascuna riga.

Ma cosa sono questi tre nuovi campi? Liquidato subito TimeStamp che corrisponde al dato “storico” che Azure Storage fissa in ciascun elemento, diciamo che:

-          RowKey dovrebbe servire a individuare univocamente il record;

-          PartitionKey, sulla carta più libero, assegna a ciascun elemento una categoria che Azure Storage utilizza per ripartire nel modo più efficiente le suddivisioni nelle sue VM, secondo il suo speciale algoritmo (totalmente trasparente a noi utilizzatori).

Per capirci, nel nostro esempietto la RowKey sarebbe un codice prodotto, ovvero quello che nei casi normali della vita viene indicato con CodProd, CodArt e simili. Esempi analoghi: ISBN (per i libri), codice fiscale e via di seguito.

Quanto alla chiave di partizione, in teoria potremmo persino definirla identica in tutti i record ad esempio con “MioProdotto”, una scelta idiota non solo priva di qualsiasi utilità ma che ostacolerebbe il corretto partizionamento e la scalabilità del sistema di storage in parola. La cosa più saggia è individuare una serie articolata di categorie, prendendo così due piccioni con una fava: far contento Azure e catalogare i nostri prodotti. In parole povere, immaginando articoli di abbigliamento, converrà adottare delle PartitionKey del tipo “Copricapi”, “Camicie”, “Giacche”, “Pantaloni”, “Abiti completi” e quant'altro.

Utilizzo dello storage in perfetto stile web

Una volta definita una classe relativa a una tabella dello Azure storage come la si gestisce? La risposta è esattamente quella che i più avveduti avranno ipotizzato, ritenendo che c’entri Internet, altrimenti di che Cloud stiamo parlando? Hanno ragione e infatti viene sfruttata l’interfaccia REST (Representation State Transfer) del protocollo HTTP in particolare mediante i verbi GET, PUT, POST e DELETE (e lo stesso vale per i blob e le queue). In questo bigino do per note le specifiche nozioni, dicendo che il libro di Cozzolino ne esemplifica dapprima l’utilizzo manuale, passando poi ad esempi di codice consentiti da provvidenziali API ad hoc (un’estensione dei WCF Data Service, come già detto). Per brevità riporto solo alcuni dei brani più significativi, con scarni commenti e facendo affidamento su una pur relativa eloquenza del codice, al di là dei suoi intrichi e bizantinismi coi quali occorrerà a suo tempo ammattire.

Accesso allo storage e definizione di un Client

Il primo passo è la definizione di credenziali di accesso alla connessione, effettuata con una nuova istanza mioAccount dello StorageCredentialsAccountAndKey, quindi di un nuovo CloudStorageAccount impostandone gli “endpoint” da utilizzare:

StorageCredentialsAccountAndKey AccountAndKey =

    New StorageCredentialsAccountAndKey("devstoreaccount1", "Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==")

    CloudStorageAccount mioAccount = New CloudStorageAccount(AccountAndKey,

    New Uri("http://127.0.0.1:10000/devstoreaccount1")

    New Uri("http://127.0.0.1:10001/devstoreaccount1")

    New Uri("http://127.0.0.1:10002/devstoreaccount1");

Ove devstorageaccount1 è l’account default. Quanto alla lunga stringa seguente posta a secondo argomento
“Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw=="

si tratta della chiave default che ci passa il convento Storage Emulator, unitamente alle le porte di accesso ai blob, alle queue e alle table, vale a dire 10000, 10001 e 10002, rispettivamente.

Subito dopo si provvederà alla creazione di una nuova istanza mioClient di un CloudTableClient di cui fornisco un esempio affidato totalmente al carattere quasi auto-esplicativo del codice:

CloudTableClient mioClient =

  New CloudTableClient(mioAccount.TableEndPoint.ToString, AccountAndKey);

String[] Tabelle = mioClient.ListTables();

Ci si accontenti di sapere e... di credere sulla fiducia che la precedente riga di codice sfrutta la proprietà ListTables di mioClient per ottenere un elenco di tutte le tabelle in esso presenti.

Creazione di una tabella

Dando sempre per intuitive le operazioni testé descritte, con discutibile audacia salto direttamente a un esempio completo per definire e creare una tabella Prodotti formata da oggetti della classe Prodotto vista sopra. Alla definizione di questa, che va messa in testa alla procedura, seguono le operazioni di accredito e di creazione di un mioClient, stavolta utilizzandone il metodo CreateTableIfNotExist con il non inatteso argomento “Prodotti”. Tale metodo, palesemente, crea la tabella a patto che non ne esista già un’omonima e altri metodi, di chiara semantica, della stessa famiglia comprendono il (normale) CreateTable, nonché DeleteTable, DeleteTableIfExist e l’appena visto ListTables.

Non è finita: gli ultimi atti del minidramma sono la creazione di un Contesto (di servizio tabellare), di tipo TableServiceContext nel quale possiamo poi aggiungere un Prodotto.

[DataServiceKey ("PartitionKey", "RowKey"]

Public Class Prodotto

{

    Public String PartitionKey { get; set }

    Public String RowKey { get; set }

    Public DateTime TimeStamp { get; set }

    Public String NomeProd { get; set }

    Public Double Prezzo { get; set }

    Public Int Giacenza { get; set }

    Public Int ScortaMin { get; set }

}

StorageCredentialsAccountAndKey AccountAndKey =

    New StorageCredentialsAccountAndKey("devstoreaccount1", "Eby8.....")

    CloudStorageAccount mioAccount = New CloudStorageAccount(AccountAndKey,

    New Uri("http://127.0.0.1:10000/devstoreaccount1")

    New Uri("http://127.0.0.1:10001/devstoreaccount1")

    New Uri("http://127.0.0.1:10002/devstoreaccount1");

// Creazione della tabella Prodotti

CloudTableClient mioClient =

  New CloudTableClient(mioAccount.TableEndPoint.ToString, AccountAndKey);

mioClient.CreateTableIfNotExist("Prodotti");

// Creazione del contesto e aggiunta di un Prodotto

TableServiceContext Contesto = mioClient.GetDataServiceContext();

Prodotto Prod = New Prodotto();

Prod.PartitionKey = "Pantaloni";

Prod.RowKey "AXY123"; //Ipotetico codice articolo

Prod.NomeProd ="Jeans vita bassa mod. 2011";

Prod.Prezzo = 250.00;

Prod.Giacenza = 450;

Prod.ScortaMin = 50

Contesto.AddObject("Prodotti", Prod);

Contesto.SaveChanges();

Commenti? Solo sulle ultime istruzioni che iniziano con la creazione del servizio Contesto di tipo TableServiceContext, ottenuto con il metodo GetDataServiceContext del mioClient. Le righe di codice che creano un nuovo Prodotto Prod e quindi ne fissano le proprietà sono parlanti, dopo di che non resta che usare i metodi del Contesto AddObject, per aggiungere Prod alla tabella Prodotti, e SaveChanges (da non dimenticare!) per consolidarne i mutamenti.

Qualche semplice query, usando LINQ

Come si è visto per usare i servizi di storage di Azure c’è da pagare lo scotto delle impostazioni per il client e il contesto. Se non ho mal compreso, queste vanno ripetute tutte le volte, comunque non sarà difficile metterci una pezza con metodi ad hoc personalizzati a dovere e ri-usabili. Dopo di che il cammino è in discesa, perché le altre operazioni tipiche di query su una o più tabelle Azure si compiono normalmente – a parte le limitazioni derivanti dalla loro natura NoSQL. Gli esempi riportati qui di seguito si basano su LINQ (Language Integrated Query) linguaggio che permette di inserire interrogazioni e modifiche direttamente nel codice C# o VB.

Esempio di filtraggio (codice LINQ in neretto):

TableServiceContext Contesto = mioClient.GetDataServiceContext();

DataServiceQuery<Prodotto> query =

  Contesto.CreateQuery<Prodotto>("Prodotti");

Prodotto Prod = query.Where(P => P.Giacenza <= P.ScortaMin;

Esempio di modifica (di un prezzo):

TableServiceContext Contesto = mioClient.GetDataServiceContext();

DataServiceQuery<Prodotto> query =

  Contesto.CreateQuery<Prodotto>("Prodotti");

Prodotto Prod = query.Where(P => P.NomeProd == "Camicia a fiori").First;

Prod.Prezzo = 500;

Contesto.UpdateObject(Prod);

Contesto.SaveChanges;

Cancellazione:

TableServiceContext Contesto = mioClient.GetDataServiceContext();

DataServiceQuery<Prodotto> query =

  Contesto.CreateQuery<Prodotto>("Prodotti");

Prodotto Prod = query.Where(P => P.NomeProd == "Camicia a fiori").First;

Contesto.DeleteObject(Prod);

Contesto.SaveChanges;

Nei vari esempi soprastanti la query viene, diciamo così, inizializzata dal metodo CreateQuery di Contesto sull’oggetto Prodotto della tabella Prodotti, dopo di che intervengono le varie istruzioni LINQ, a valle delle quali i metodi del Contesto UpdateObject, DeleteObject seguiti dal già visto SaveChanges compiono i mestieri che i rispettivi nomi a chiare lettere denitano.

E l’ordinamento? Come già anticipato con questo genere di tabelle è possibile solo sulla chiave PartitionKey (del che, forse errando, personalmente oso dubitare) e una clausola OrderBy viene sistematicamente rigettata a ostinati & illusi.  Ci si può però arrangiare assegnando a una query il metodo ToList e applicando OrderBy all’elenco così ottenuto, anche se con qualche limite su cui rimando al testo di Cozzolino.

SQL or NoSQL? Questo il dilemma

Analogamente si possono re-inventare operazioni di tipo join o lookup, ma senza fruire dello standard del modello relazionale cui molti erano abituati fin dai tempi del glorioso Clipper.

Ma non va dimenticato che Cloud pubblico targato Microsoft fornisce anche Azure SQL che, ripeto, equivale a SQL Server 2008 R2 (ma al momento, temo, con qualche limite nelle feature più pregiate). E in questo ambiente tutto procede secondo il modello relazionale. Dunque una manna – fissazione di client e contesti a parte – per chi era già familiare con SQL Server. Ma allora perché ricorrere al meno “rigoroso” cugino NoSQL? La risposta dipende soprattutto dalla dimensione massima di immagazzinamento, molto maggiore con table storage (fino a 100 Terabyte) appetto agli odierni 50 Gbyte massimi che passa il convento SQL Azure. A sua volta table storage non supporta tutti i tipi di dato dell’altro. Un altro aspetto problematico si ha con le query che restituissero più di 1000 unità. Verificate, gente, verificate.

La questione è particolarmente complessa e va studiata accuratamente, caso per caso. A caldo sembrerebbe che table storage si presti poco al ri-uso, non solo per la conversione di preesistenti tabelle “on premises” ma anche per quanto riguarda le procedure, generalmente ispirate ai concetti relazionali (andranno riscritte in gran parte), mentre si presenta particolarmente idoneo per nuove applicazioni web, di tipo ASP o Silverlight.

Ma quanto mi costi?

Encomiabile è infine l’Appendice nella quale Cozzolino si è sforzato di valutare costi di una soluzione Cloud di tipo pubblico PaaS basata su Azure. Di grande interesse e particolarmente convenienti sono le soluzioni di fascia bassa, a partire da quella introduttiva, gratuita, per chi volesse sperimentare il nuovo mondo (si paga solo a consumo quel che si sfora rispetto all’offerta base).

I conti fatti dal nostro cambiano se si passa a un sistema informativo medio. Egli li valuta in un canone annuo di 6000 euro più spese ulteriori a consumo. Queste, con somma sorpresa  di quanti sentono in giro parlare di costi prevalentemente “on demand” nel mondo Cloud, sono trascurabili se non irrisori. Si veda però la NOTA FINALE. Cozzolino paragona il tutto a una serie di normali server equivalenti, di prezzo pari a circa 8000 euro cui vanno aggiunti i costi delle licenze (incluso SQL Server, presumo, mentre SQL Azure è compreso nel canone Azure) e, naturalmente, quelli energetici e di manutenzione tutti a carico Microsoft. Personalmente mi permetto di obiettare che, a fronte di un canone annuo di Azure, i prezzi di acquisto dell'equivalente "on premises" andrebbero divisi per tre o per cinque, a seconda che si applichi il criterio dell’obsolescenza tecnologica o il più sparagnino ammortamento fiscale. In particolare tale discorso vale per la seconda alternativa, indicata sempre da Cozzolino, ovvero un server virtualizzato di ultima generazione che sostituisce i normali server predetti (con notevoli altri vantaggi di consolidamento ed efficienza) con ulteriori margini di espandibilità, al prezzo di 15000 euro...

NOTA FINALE - Il "canone" di cui sopra va inteso come dato indicativo MEDIO. In realtà anche Azure offre la possibilità di tarare i servizi base on demand, in particolare variando anche dinamicamente le VM necessarie, tipicamente aumentandole in periodi di punta e riducendole in quelli più tranquilli. Personalmente penso che per un'azienda normale siano difficili operazioni raffinate per cui dovrà fissare una configurazione base che assicuri la normale operatività con un certo margine. La faccenda comunque richiede una riflessione accurata. 

Mi fermo qui, dichiarando doverosamente che Azure è un mondo molto più ricco di quanto questo sguardo introduttivo potrebbe indurre a pensare. Esso infatti offre diversi comodi servizi, come i blob storage (corredabili di metadati e per una più organica classificazione e ricerca, utilissima in cataloghi sul web, la gestione di code) e  tool innovativi (AppFabric o Service Bus, per buttar lì due nomi a caso) che aprono prospettive interessanti. Con le quali prima o poi si dovranno fare i conti.

giannigiac@tin.it

Un tormentone che mi assilla da tempo è relativo alla gestione di Window multiple. I problemi cui si va incontro sono due:

• 1)      navigare fra le diverse istanze aperte;
• 2)      passare valori o modificare oggetti  dall’una all’altra.

Sul secondo, in un post di questo Forum ho escogitato una very dirthy patch, sporca perché crea una nuova  finestra principale (MainWindow o, comunque, quella definita con StartupURI = “. . .” in Application.xaml. In fondo a questo articolino riporto la soluzione suggerita dall’ottimo Sarati: più pulita della mia ma che comunque si direbbe che anch’essa ricorra “a suo modo” a un ‘istruzione che crea una nuova istanza di MainWindow dall’interno della finestra secondaria (a sua volta creata  “come nuova” nella MainWindow d’apertura.

Sia come sia, nel frattempo ho rivisto nella parte introduttiva del libro di Alessandro del Sole- VISUAL BASIC OLTRE IL CODICE – Ed. FAG – il codice Application.Current.Windows che dà adito alle finestre attualmente aperte. Interessante!  Fusse che fusse la volta buona per il mio (e altrui, credo) tormentone?

Il piccolo ma istruttivo esperimento che sto per proporre dovrebbe servire allo scopo. Si crei in aggiunta alla finestra primaria MainWindow una secondaria Window1, entrambe dotate di un semplice Button come il seguente, la prima dotata di Title=”Finestra primaria” la seconda di Title=”Finestra secondaria:

<Button Name="EsploraFinestre"   Content="Esplora finestre aperte" ... />

Cliccando sul primo viene creata una nuova istanza di Window1,ma prima si hanno varie istruzioni MessageBox.Show che evidenziano Application.Current e i suoi figli Window.

Codice VB della MainWindow:

Class MainWindow

    Dim MiaApplic As Application = Application.Current

    Private Sub EsploraFinestre_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles EsploraFinestre.Click

        MessageBox.Show("Ciao", "sender: " & sender.ToString)

    For Each win As Window In MiaApplic.Windows

        MessageBox.Show(win.Title) ' => solo l’ISTANZA MainWindow (Window1 ancora "ignota")

    Next

        MessageBox.Show("window primario: " & MiaApplic.MainWindow.ToString)

        Dim Win1 = New Window1

        Win1.Show()

        If MessageBox.Show("Chiudiamo la finestra primaria?", "Rispondi Si o no", 

                MessageBoxButton.YesNo) = MessageBoxResult.Yes Then

            Me.Close()

        End If

    End Sub

End Class

 

Le varie MessageBox.Show si commentano da sole, insisto solo sul fatto che nel ciclo For Each win As Window in MiaApplic.Windows. . . Next è la MainWindow, sola soletta, a venir indicata. Così afferma nel suo analogo esempio Alessandro ipotizzando possibili diverse situazioni. Bene, vediamo cosa accade con la Win1 creata e mostrata nelle istruzioni successive e si tenga presente la richiesta finale di chiusura o meno di MainWindow.

Codice VB della Window1:

Public Class Window1

    Dim MiaApplic As Application = Application.Current

    Private Sub EsploraFinestre_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles EsploraFinestre.Click

      MessageBox.Show("sender: " & sender.ToString & vbLf & "Numero Windows aperte: " & MiaApplic.Windows.Count)

        For Each win As Window In MiaApplic.Windows

            MessageBox.Show(win.Title) ' => sia la CLASSE Window1 che MainWindow ma solo se ancora attiva)

        Next

        ' Se MainWindow era stata chiusa, l'istruzione seguente dà errore:

        ' MessageBox.Show("window primario: " & MiaApplic.MainWindow.ToString)

        ' Si può rimediare anteponendo:

        If MiaApplic.MainWindow Is Nothing Then Exit Sub

        MessageBox.Show("window primario: " & MiaApplic.MainWindow.ToString)

            MiaApplic.MainWindow.Activate()

        End If

    End Sub

End Class

 

I punti chiave sono il codice MiaApplic.Windows.Count e il ciclo For Each win  ...Next: se MainWin non era stata chiusa il primo è pari a 2, mentre il secondo indica sia MainWindow che Window1. A questo punto ci si può divertire passando MANUALMENTE alla finestra principale e cliccarne l’unico Button, constatando che se non si accetta Me.Close il pulsante della finestra secondaria può indicare anche più di due istanze di Window1, per giunta OMONIME! Una confusione da evitare opportunamente in una soluzione reale (v. anche il suggerimento di utilizzare piuttosto Me.Hide di Serati).

Qui comunque ci stiamo divertendo. Perciò proseguiamo l’esperimento completando la parte bassa  della routine dell’evento Click del Button della finestra secondaria come segue:

        If MessageBox.Show("Vuoi attivare la finestra primaria?", "", MessageBoxButton.YesNo) = MessageBoxResult.Yes Then

            ' Purtroppo il passaggio di valori a tale istanza non sembra possibile:

            ' MiaApplic.MainWindow.EsploraFinestre.Content = "Evviva me!" ' Rigettata: il compilatore non vede gli oggetti di MainWindow

            ' MiaApplic.MainWindow.VarComune = "Buona notte!" ' E nemmeno variabili comuni, Public, Shared (o di altro tipo?)

            ' Comunque è possibile attivare la finestra principale!! Eureka!

            ' Anche se non basta per il passaggio valori, a fortiori vietata A VALLE di:

            MiaApplic.MainWindow.Activate()

        End If

    End Sub

End Class

 

I commenti e la pratica mettono in luce due punti:

·         MiaApplic.MainWindow.Activate() equivaleperfettamente  alla manovra manuale di attivazione della finestra primaria; Eureka!

·         né i controlli né i valori di variabili comuni (dimenticavo: una VarComune definita a livello Dichiarazioni nella MainWindow) si possono vedere, né tantomeno modificare.

CONCLUSIONI, su cui spero in un dibattito:

A)     Siamo in presenza di un ginepraio SEMANTICO, che rende davvero sottile distinguere fra “robe” come MainWindow e Window1 intese come CLASSI e relative ISTANZE (????)

B)      Alla luce di questo esperimento sembrerebbe inevitabile il “sudicio” ricorso a un’istruzione Dim MiaMainW As New MainWindow  e simili se si vogliono modifiche a elementi da una Window a un’altra.

Comunque “sento” di essere  a un passo dalla meta. Il giallo continua.

. . . . .

Soluzione del giallo

Pensa e ripensa alla fine mi sono reso conto che consiste nell’utilizzo dell’evento Activated di MainWindow. Per dare maggior concretezza alla trovata, inseriamo un paio di controlli nelle due finestre:

• ·         nella MainWindow una Label di nome “lblMainW” e di contenuto default, putacaso, “Oggi c’è il sole”;
• ·         nella Window1 una TextBox denominata “txtBoxW1”.

Fermo restando il ciclo della routine dell’evento Click del Button “EsploraFinestre”di  Window1” e imponendo che esso culmini con l’istruzione fatidica MiaApplic.MainWindow.Activate() [ per semplicità, ignoriamo casistiche alternative, magari foriere di bug, che qui non interessano...] ecco infine una versione conclusiva, ridotta all’essenziale della Sub relativa all’evento Click del Button “EsploraFinestre” di MainWindow:

 Class MainWindow

    Dim MiaApplic As Application = Application.Current

    Dim Win1 As Window1

    Private Sub EsploraFinestre_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles EsploraFinestre.Click

        Win1 = New Window1

        Win1.Show()

        If MessageBox.Show("Chiudiamo la finestra primaria?", "Rispondi Si o no", MessageBoxButton.YesNo) = MessageBoxResult.Yes Then

            Me.Close()

        End If

    End Sub

 

    Private Sub Window_Activated(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Activated

        lblMainW.Content = Win1.txtBoxW1.Text

    End Sub

End Class

 

A buon intenditor altre parole sarebbero sprecate? Si e no, perché a ben riflettere il sudicio trucco MiaMainW As New MainWindow  potrebbe servire nel caso si fosse deciso per Me.Close prima di creare ed esibire la seconda Window1 (v. comunque la soluzione di Serati qui sotto).

Insomma, a ciascuno il suo.

E NON È TUTTO: Application.Current.Mainwindow non espone soltanto il metodo Activate ma - ovviamente a condizione che MainWindow sia effettivamente APERTA – tutte le sue proprietà e metodi.

CONCLUDENDO, propongo un esempietto che sfrutta entrambi i trucchi dal sottoscritto sperimentati. Si abbia una MainWindow e una finestra secondaria Window1. Nell’una e nell’altra esiste un pulsante di richiamo mutuo. Ecco la routine di quello presente in MainWindow:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles Button1.Click

        Dim W As New Window1 ‘ Crea un’istanza di Window1

        W.Activate()

        W.Show()

        If MessageBox.Show("Chiudo (o nascondo) la finestra principale?", "Rispondi", MessageBoxButton.YesNo) _

            = MessageBoxResult.Yes Then

            Me.Close()

        Else

            Me.Hide()

        End If

    End Sub

 

Lo scopo, didattico, è quello di proporre l’alternativa di chiusura vs. quella di occultamento di MainWindow. Nel primo caso, come si constata dopo qualche patimento, il codice Application.Current.Mainwindow.Activate dà errore a run-time. Di qui la Sub del Button1 della finestra secondaria:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles Button1.Click

        If Application.Current.MainWindow Is Nothing Then

            Dim MW As New MainWindow

            MW.Activate()

            MW.Show()

            MW.Title = "PRIMARIA"

        Else

            With Application.Current.MainWindow

                .Activate()

                .Show()

                .Title = "PRINCIPALE"

            End With

        End If

        Me.Close()

 End Sub

 

Come si vede, essa evita la gestione dell’errore semplicemente testando Application.Current.MainWindow  Is Nothing: in caso affermativo si ricorre al trucco sudicio di creazione di una nuova istanza MW di MainWindow, altrimenti  si utilizza quella che era stata semplicemente nascosta ma tuttora in vita.

Notare infine che nell’uno e nell’altro caso, a dimostrazione della possibilità di passare proprietà e valori da Window1 a MainWindow,  viene modificata una proprietà a caso, nella fattispecie Title di MainWindow (supposta per default “Mainwindow”) resa pari a “PRIMARIA” oppure “PRINCIPALE” al solo scopo didattico  di diversificare le due situazioni.

 

 

La brillante soluzione Sarati

PROBLEMA:
C'è una finestra principale con una Textbox e un Button che deve mostrare una finestra secondaria chiudendosi.
La finestra secondaria, anche essa con una textbox e un bottone, all'inizio mostra nella textbox il contenuto della finestra principale. Al click del bottone rimostra la finestra principale.


TERMINOLOGIA:
- MainWindow = nome della CLASSE della finestra principale
- originWindow = ISTANZA di MainWindow
- ChildWindow = nome della CLASSE della finestra secondaria
- subwindow = ISTANZA di ChildWindow

ESEMPIO1:

Class MainWindow

    Private subWindow As ChildWindow = Nothing

    Private Sub ButtonMain_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles ButtonMain.Click

        subWindow = New ChildWindow(Me) 'istanza della finestra secondaria

        Me.Hide() 'nasconde se stesso

        subWindow.Show() 'mostra la finestra secondaria

    End Sub

End Class

 

Public Class ChildWindow

    Private originWindow As MainWindow = Nothing

    Public Sub New()

        InitializeComponent()

    End Sub

    Public Sub New(ByVal m As MainWindow) 'COSTRUTTORE USATO

        InitializeComponent()

        Me.originWindow = m 'Salva instanza in propriet&#224;

        Me.TextBoxChild.Text = Me.originWindow.TextBoxMain.Text

    End Sub

    Private Sub ButtonChild_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles ButtonChild.Click

        Me.Hide() ' nasconde me stesso

        Me.originWindow.TextBoxMain.Text = Me.TextBoxChild.Text

        Me.originWindow.Show() 'mostro finestra di origine

    End Sub

End Class


PROBLEMI. L'applicazione non si chiude se si fa clic sulla x della ChildWindow. Per risolvere si deve mettere in Application.xaml la proprietà ShutdownMode="OnMainWindowClose" e poi chiudere con originwindow.Close() all'evento OnClose della childWindow (oppure mostrare la finestra principale...)

ESEMPIO2:
Per il problema "agire direttamente e senza equivoci su tutti gli oggetti del foglio o documento aperto" puoi agire così: Mettere una classe con proprietà statica a tutte le finestre che crei:  

Public Class WindowReferences 'da ovunque puoi accedere a questi oggetti

    Public Shared originWindow As MainWindow

    Public Shared subWindow As ChildWindow

End Class


e ovunque accedi con quei puntatori:  

Class MainWindow

    Public Sub New()

        InitializeComponent()

        WindowReferences.originWindow = Me

        WindowReferences.subWindow = New ChildWindow()

    End Sub

    Private Sub ButtonMain_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles ButtonMain.Click

        Me.Hide() ' nasconde se stesso

        WindowReferences.subWindow.TextBoxChild.Text = Me.TextBoxMain.Text

        WindowReferences.subWindow.Show() 'mostra la finestra secondaria

    End Sub

End Class

Public Class ChildWindow

    Public Sub New()

        InitializeComponent()

    End Sub

    Private Sub ButtonChild_Click(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs) Handles ButtonChild.Click

        Me.Hide() ' nasconde me stesso

        WindowReferences.originWindow.TextBoxMain.Text = Me.TextBoxChild.Text

        WindowReferences.originWindow.Show() 'mostro finestra di origine

    End Sub

End Class

CONCLUSIONI: Personalmente a me non piace come approccio... Avere una finestra principale che scompare non mi pare bello. Inoltre, se memorizzi le istanze delle finestre secondarie, ricorda che tieni in memoria tutte le finestre! Inoltre devi evitare (come dicevo prima) i Close (da sostituire con Hide altrimenti l'istanza non è più utilizzabile).

A me continua a piacere una singola finestra principale sempre visibile, e se serve una secondaria, la principale è visibile e la secondaria la mostro con ShowDialog.

Detto questo, il codice sopra è un esempio... ci sono molti affinamenti da fare...

 

Fino a ieri chi programma applicativi invidiava in cuor suo la semplicità offerta dal “linguaggio” (dichiarativo) HTML e derivati per creare pagine Web davvero ricche. Ah poter lavorare con altrettanta facilità da codice VB, C# e compagnia cantante! WPF e Silverlight consentono di farlo in vari modi, il più diretto e comodo è il potente oggetto FlowDocument , sostanzialmente in virtù dell’adozione della sua anima, appunto, dichiarativa: l’XAML.

Piccola digressione. Ma l’XML, di cui XAML è figlio, non è nato in origine per separare dati e formati? Vero, ma presto ci si è resi conto che la sua flessibilità permette schemi di qualsiasi tipo, invadendo così anche scopi formattanti. Si pensi al formato Open XML di Office 2008 e 2010, che comprende componenti dedicati ai formati di celle Excel, paragrafi, parole di Word. (Che poi ne derivi una certa confusione è un’altra, anzi è la solita storia Informatica…).

 La classe FlowDocument è relativa a un oggetto potente, un vero e proprio documento di testo che si articola in oggetti-figli genericamente catalogati come Block (v. Guida), ma che in pratica hanno nomi eloquenti. Il più importante è Paragraph – uno o generalmente più d’uno -, cui corrisponde in XAML una coppia di tag omonime entro la quale si può inserire un brano di testo. A sua volta un sub-testo può essere  racchiuso fra <Bold>...</Bold> o <Italic>...</Italic> ecc., a denotare e far apparire a video grassetti, corsivi e quant’altro. Ancor più bella è la possibilità di includere altri oggetti d’ogni tipo, come forme, immagini  nonché controlli.

In questo piccolo tutorial entro in medias res con un esempio semplice ma tipico. Prima è necessaria una premessa:

Un FlowDocument deve essere racchiuso in un contenitore. Il più potente e comodo dei quali è lo specifico FlowDocumentReader. In pratica in XAML si avrà una situazione come la seguente:

Figura 1

Quest’altra figura illustra una situazione dopo varie manovre tramite il lettore e allargamento della finestra fino a visualizzare l’intero documento.

 Figura 2

Si osservi l’adeguamento automatico della larghezza dei paragrafi nonché la presenza di un grassetto, un corsivo, tre pulsanti di opzione, una lista con quattro elementi , due dei quali corredati di shape, e un pulsante di comando. La figura precedente mostra quel che accade cliccando su di esso.

Per non deludere Impazienti & Curiosi ecco la banale routine responsabile, associata all’evento Click di tale Button, denominato per eccesso d’immaginazione, puls1:

Sub Raddoppia()

    Dim pulsH = puls1.Height

    Dim pulsW = puls1.Width

    puls1.Height *= 2 : puls1.Width *= 2

    MessageBox.Show("Ora ripristino le dimensioni del pulsante")

    puls1.Height = pulsH

    puls1.Width = pulsW

End Sub

Tutto il codice XAML

Dopo quanto detto ritengo quasi del tutto sufficiente riportare la parte dichiarativa del programmino, affidandomi all’eloquenza delle varie tag. Aggiungo solo che per prendere due piccioni ho utilizzato anche un controllo Expander, a monte del FlowDocumentReader. In tal modo il nostro documento può essere collassato (e occultato) o espanso per una sua più o meno ampia visualizzazione.

<Window x:Class="MainWindow"

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

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

    Title="FlowDocumentReader" Height="450" Width="525">

    <Grid>

        <Grid.RowDefinitions>

            <RowDefinition Height="250*" />