Abilitazione via XAML
Come spiegato da Alessadro, basta includere l’assembly PresentationFramework.Aero.dll tra le risorse dell’applicazione e poi aggiungere queste righe all’interno del file App.xaml, per fare in modo che tutta l’applicazione usi il tema Aero.

Il secondo dizionario che viene usato contiene altri temi aggiuntivi, quindi non e’ indispensabile per abilitare Aero. L’ho messo solo come nota per far vedere come includere e usare stili presi da altri assembly all’interno dello stesso App.xaml.

Il risultato che si ottiene e’ questo, conservando un look’nd feel omogeneo tra Windows XP e Windows Vista, contorno della finesta a parte:

Abilitazione via codice
Se l’abilitazione del tema occorre farla via, basta includere queste righe nell’evento OnStartup dell’applicazione, file App.xaml.cs e sempre dopo aver referenziato PresentationFramework.Aero.dll:

ResourceDictionary aero = new ResourceDictionary();
aero.Source = new Uri("/PresentationFramework.Aero;V3.0.0.0;31bf3856ad364e35;component/themes/aero.normalcolor.xaml", UriKind.RelativeOrAbsolute);
Application.Current.Resources.MergedDictionaries.Add(aero);

ResourceDictionary dict = new ResourceDictionary();
dict.Source = new Uri("/ComNet.Retail.UI.WPF.Touch;component/Themes/GlobalStyles.xaml", UriKind.RelativeOrAbsolute);
Application.Current.Resources.MergedDictionaries.Add(dict);

Stesso discorso fatto sopra per i temi aggiuntivi vale anche per la seconda parte di questo snippet, quella importante e’ solo la prima sezione di codice.

Abilitazione selettiva via XAML
Si puo’ anche fare in modo che solamente una finestra dell’applicazione utilizzi il tema Aero, mentre il resto del programma continui ad utilizzare il suo tema predefinito.

Anche in questo esempio, ho aggiunto una parte non funzionale all’impostazione del tema, quella del ResourceDictionary che contiene la dichiarazione del Converter e dello Style. Serve solo per far vedere come mettere tutto assieme all’interno delle Window.Resources.

Abilitazione selettiva via codice
All’interno del code behind della mia Window, UserControl o altro elemento grafico, basta scrivere:

ResourceDictionary aero = new ResourceDictionary();
aero.Source = new Uri("/PresentationFramework.Aero;V3.0.0.0;31bf3856ad364e35;component/themes/aero.normalcolor.xaml", UriKind.RelativeOrAbsolute);
this.Resources.MergedDictionaries.Add(aero);

Io personalmente utilizzo questo codice nel costruttore dell’elemento, dopo la chiamata InizializeComponent(), ma si puo’ usare dove serve, senza problemi, dipende dall’uso che viene fatto degli stili all’interno della window o controllo e se vengono definiti come StaticResource o DynamicResource (rispettivamente prima di InizializeComponent() o un po’ ovunque nell’inizializzazione del controllo).

Precauzioni varie
Se si vogliono definire ulteriori personalizzazioni all’aspetto dei controlli, bisogna utilizzare l’attributo BasedOn nella definizione dello stile, altrimenti si perde l’aspetto Aero. Ad esempio, per definire larghezza e altezza minina di un bottone:

Questo stile potrebbe essere definito in un file WPF separato ed incluso con gli snippet di codice che facevo vedere sopra.

Dopo essersi letti un po’ di teoria, passiamo alla realizzazione di una vera classe C# da utilizzare all’interno di un programma VB6.

Come specificato nel post precedente, se si utilizza VB.NET c’e’ gia’ un template di progetto pronto per l’interoperabilita’. Utilizzando invece C# (o VB.NET con Visual Studio 2008) occorre farsi le cose a manina. Di seguito uno snippet di codice per creare la classe di base.

using System;
using Microsoft.VisualBasic;

namespace TestRegistazioneCom
{

[ComClass(TestComInterop.ClassId, TestComInterop.InterfaceId, TestComInterop.EventsId)]
public class TestComInterop
{
	public const string ClassId = "233D23FD-68C0-4da6-9749-8E137127692F";
	public const string InterfaceId = "6ACCBB64-3A0A-46ee-B8F8-9537CEBF2136";
	public const string EventsId = "B6A186AB-6212-4ab1-B998-7F471C5AE94B";

	public TestComInterop()
	{
	}

	public string GetName()
	{
		return "RainbowBreeze";
	}
}
}

I GUID (quelle lunghe stringe di numeri) vanno cambiati e messi nuovi, magari utilizzando il GUID Generator di Visual Studio (Tools -> Create Guid)

Configurazione del progetto .NET per l’interoperabilita’

Andare nelle proprieta’ del progetto, tab Application, bottone Assembly Information

Title: il titolo dell’assembly, viene messo in HKEY_CLASSES_ROOT ed e’ quello che apparira’ come nome della libreria creata
Description: la descrizione che apparira’ dentro VB6 quando si andranno ad aggiungere nuove reference
Version: la versione con cui la libreria .NET viene registrata
GUID: il GUID utilizzato per registrare l’oggetto all’interno del registry (HK_CR\TypeLib\). Viene generato automaticamente e deve essere univoco per non sovrapporsi ad altri GUID di altre librerie registrate nel sistema  Make Assembly COM-visible: va flaggata questa opzione

Registrazione della nuova DLL nel sistema

Se nelle proprieta’ del progetto .NET, tab Build, viene impostata la voce “Register for Com Interop“, quando il progetto viene compilato, Visual Studio pensa anche a generare il relativo tlb (un proxy per VB6 necessario all’interoperabilita’) e registrarlo all’interno del sistema. Se questo puo’ sembrare un comodo automatismo, in realta’  va bene solo per la macchina di sviluppo, dato che il tlb viene generato all’interno della cartella bin\debug o bin\release del progetto e registrato in quel percorso.

Nella macchina di deploy, occorre registrare manualmente il tlb generato, per mezzo del comando regasm.exe: copiare la dll .NET nella cartella dove andra’ a finire in maniera definitiva, e poi eseguire il comando regasm per generare il tlb e registrarlo nel sistema. Ponendo che la classe da registrare si chiami TestRegistrazioneCom.dll, la sintassi del regasm sara’:

regasm TestRegistrazioneCom.dll /tlb:TestRegistrazioneCom.tlb

Come ultimo passo, occorre registrare la DLL .NET della GAC (Global Assembly Cache), in modo che il tlb sappia chi chiamare quando i suoi metodi vengono invocati. In alternativa, si puo’ anche lasciare la dll .NET nella stessa cartella dell’eseguibile VB6, senza bisogno di registrazioni nella GAC.

Utilizzi avanzati

Se si vuole costruire una nuova classe .NET che deve pero’ mantenere la compatibilita’ con un precedente oggetto COM, andandolo a sostituire in maniera trasparente alle applicazioni che lo utilizzano, si puo’ agire sul GUID e sul Title del nuovo progetto .NET, impostandoli come quelli della classe da sostituire. Occorrera’ poi accertarsi che anche i metodi esposti siano gli stessi. Con questa attenzione, basta deregistrare la vecchia libreria VB6 e registrare la nuova libreria .NET e tutto dovrebbe andare.

Altre guide che parlano della COM Interop, invece di registrare direttamente la classe .NET concreta, registrano un’interfaccia, che poi la classe .NET va ad implementare.
Mi sembra una soluzione piu’ pulita, ma alla fine ogni soluzione ha il suo contesto corretto.

References:
Interop Forms Toolkit 2.0 Tutorial – assolutamente da leggere
VB6 Interop – Bringing VB6 into the .NET fold
Using .NET Controls in VB6

Non esiste un metodo universalmente riconosciuto e usato per fare tutto questo in .NET, anche se ci sono strumenti e pattern più o meno complessi il cui uso e’ pertinente a determinate situazioni.

WINFORM – LA VIA FACILE

L’articolo MSDN relativo e’ questo: Walkthrough: Localizing Windows Forms.
In pratica, se occorre localizzale label, menu e altri elementi di un form, il compito e’ semplice e viene fatto tutto grazie all’editor di Visual Studio. Si disegna la propria finestra e si impostano tutte le etichette standard, quelle che devono apparire di default. Si passano poi a definire le traduzioni per un certo linguaggio impostando la proprieta’ Language del form e modificando le etichette dei controlli. Il sistema, in fase di esecuzione dell’applicativo, provvedera’ a selezionare uno dei linguaggi personalizzati basandosi su quello del sistema. Se invece si vuole impostare una lingua, occorre agire su Thread.CurrentThread.CurrentUICulture. Tutto funziona grazie ad un file di risorse, creato automaticamente dall’editor, per ogni finestra  / controllo che localizzo con questo medoto.
Approccio molto simile per ottenere delle stringhe localizzate, utili per MessageBox e altre informazioni da mostrare all’utente. Si crea un file delle risorse (quello di default e quelli specifici per le lingue gestite), si inseriscono in questi file le coppie chiave/valore (nel valore c’e’ il testo tradotto) e poi da codice si usa un ResourceManager, legato al file delle risorse creato, per ottenere i valori delle chiavi richieste in base alla cultura corrente.
Pro di questo metodo l’estrema facilita’ di implementazione e la scrittura di poco codice, contro il fatto che occorre ricompilare e ridistribuire il progetto ad ogni cambiamento dei testi e che le risorse localizzate non risiedono in un unico punto ma sono sparse all’interno dell’applicazione.

Per localizzare anche i componenti che mostrano date e valute, occorre agire su Thread.CurrentThread.CurrentCulture, seguendo quanto scritto in How to: Set the Culture and UI Culture for Windows Forms Globalization.

ASP.NET – RESOURCE PROVIDER PER TUTTI

ASP.NET 2.0 Localization Features: A Fresh Approach to Localizing Web Applications: l’articolo di riferimento da leggere per la localizzazione delle applicazioni un ASP.NET 2.0
Introduction to Localization in ASP.NET 2.0: questo articolo, che attinge a larga mano dal precedente, espone alcuni concetti di base della localizzazione in ASP.NET 2.0, parlando di assembly delle risorse (gli stessi utilizzati in maniera trasparente nell’approccio WinForm precedente), spiega come impostare una pagina in base alla lingua predefinita nel browser dell’utente, fa una panoramica su risorse globali (GetGlobalResourceObject) e risorse locali (GetLocalResourceObject), su come funziona il Resource Fallback, su come assegnare via markup code il testo dei controlli nella pagina asp grazie alle Implicit ed Explicit Resource Expressions.

Punti di debolezza di questi approcci, il fatto che i resource file sono gestiti automaticamente e non si possono condividere, ad esempio, con una versione WinForm della stessa applicazione. Inoltre, come il precedente, ogni cambiamento delle risorse necessita di una ricompilazione e ridistribuzione di parti dell’applicazione.

WINFORM e ASP.NET – GESTIONI PIU’ COMPLESSE

Se l’uso dei file di risorse dell’applicazione non e’ quello che si vuole usare, perche’ magari le traduzioni devono risiedere su un database oppure devono essere distribuite attraverso file xml, se occorre tenere in considerazione l’orientamento del testo della cultura scelta nel disegno del form, se per ognuna occorre anche ridimensionare label e textbox o cambiare immagini e colori, allora le due precedenti “via facili” non sono piu’ sufficienti.

Fortunatamente ASP.NET offre la possibilita’ di definire dei custom resource provider, in grado di accedere alle risorse fuori dall’ambito dell’App_GlobalResources e dell’App_LocalResources. Ad esempio alimentandosi da un database o da un assembly esterno.
Extending the ASP.NET 2.0 Resource-Provider Model mostra come implementare un proprio Database Resource Provider, prestando attenzione a fattori come il resource fallback, il caching, l’accesso multithreading al database e l’impostazione dellla sezione <globalization> del Web.config per usare il proprio resource provider. Segue anche una trattazione per attingere i dati da un assembly esterno. per la lettura dei dati.
Creating a Data Driven ASP.NET Localization Resource Provider and Editor: seguendo l’approccio del precedente articolo, viene costruito un Database Resource Provider ed un editor ASP.NET per modificare agevolmente le risorse. Trattazione esplicita e molti esempi di codice, con la definizione completa  e puntuale di tutto quello che va implementato.

Per quanto rigurda le applicazioni WinForm invece non esiste un approccio standard alla risoluzione di questi problemi, e occorre fare molte cose via codice esplicito, creandosi il proprio dizionario dove contenere le traduzioni localizzate, modificare attraverso il codice label, titoli, posizioni e quant’altro occorre considerare per la cultura corrente.
Oppure passara a WPF.

LOCALIZZAZIONE IN WINDOWS PRESENTATION FOUNDATION (WPF)

Il discorso si fa ampio e complesso perchè WPF e’ pensato per la localizzazione piu’ totale, quindi sono molte le possibilità offerte, ognuna con i suoi pro e contro e con determinati aspetti tenuti in considerazione: verso di scrittura, (sinistra-destra oppure destra-sinistra) grandezza dei controlli che si devono o non devono autoridimensionare a secondo del testo in essi contenuto.
cultura di fallback, quella cioe’ da usare se non esiste la specifica cultura impostata nel sistema operativo in uso, l’uso del tag Xml:lang, possibilita’ di modificare a runtime la cultura usata. I risultati, comunque, sono abbastanza semplici da ottenere.

Un po’ di teoria:
WPF Globalization and Localization Overview: best practices nel disegno di interfacce multilinguaggio, definizione di un language-neutral main assembly per il progetto e dei language-dependent satellite resource assembly dove inserire le proprie risorse localizzate. Utilizzo del tag Uid negli elementi del file xaml.
Globalization for the Windows Presentation Foundation: Aggiunge, rispetto al precedente, qualche raccomandazione per l’uso di ClickOnce

Ed alcuni esempi hands-on:
Globalization and Localization Samples: una serie di esempi tratti dalla MSDN che fanno vedere varie tecniche di localizzazione focalizzate su piccole e semplici tematiche.
WPF Multi-Lingual at Runtime: localizzazione delle stringhe di un xaml mediante file xml. Soluzione semplice per situazioni semplici, la lettura del primo commento “My favorite approach” suggerisce come alleggerire un po’ il file xml e lo xaml.
Localizing WPF Applications using Locbaml: in realta’ tre articoli in uno, questo esauriente tutorial si approccia alla locazzazione di un’applicazione WPF seguendo tre diverse strade: la prima utilizza il Resources.resx, la classe Properties.Resources e un po’ di sano binding nello xaml. La seconda invece crea delle satellite dll, usa gli Uid degli elementi dello xaml, usa MSBuild.exe e LocBaml.exe e altri concetti. La terza e’ un’ulteriore raffinazione della seconda tecnica. Personalmente ho trovato il primo approccio semplice e abbastanza utile. Inoltre, non ho neanche dovuto ridefinire il ResXFileCodeGenerator grazie al commento “Found I didn’t need the custom code generator“, ho notato che l’editor xaml di Visual Studio 2008 offre pieno supporto a questo approccio, senza i problemi che ha avuto l’autore. Occorre pero’ correggere il contenuto del tag <Button> sostituendo la stringa
“{x:Static properties:Resources.MainButtonText}”
con la stringa
<TextBlock TextAlignment=”Center” Text=”{x:Static properties:Resources.MainButtonText}”/>

Real-Time Multilingual WPF Demo: un progetto che si appoggia sul servizio di traduzione online offerto da Google per ottenere on-the-fly le stringhe da tradurre in base ad un linguaggio di origine e uno di destinazione impostabili a runtime. Prevede anche l’uso di una custom markup extension per rendere più facile da scrivere il codice xaml.

Ci sono poi delle librerie che permettono di usare altri modi di gestire la localizzazione di stringhe e immagini, senza dover usare LocBaml, file di risorse ed altro.
WPF Localization by Tomer Shamam:
i dizionari usati per le traduzioni possono essere creati in maniera disaccoppiata dalla forma di persistenza, potendo quindi usare xml, database o altro, prevede l’utilizzo di parametri bindabili nelle stringe localizzate ed e’
inclusa anche una markup language extension per rendere piu’ elegante e semplice la scrittura dello xaml. Permette di bindare qualunque
attributo dei controlli, ad esempio la larghezza di una label, nel codice viene mostrato come usare diverse immagini a secondo della lingua usata. Gestiti i valori di default, update automatico delle proprieta’ localizzate dei controlli a runtime, supportati i DataTemplate ma non la localizzazione dei ContextMenu.
WPF LocalizeExtension by SeriousM: utilizza file di risorse (.resx) per memorizzare i contenuti da localizzare, senza passare quindi per le satellite dll e supportando il .resx-fallback mechanism (en-us -> en -> independent culture). Custom markup extension per la scrittura semplificata dello XAML, possibilita’ di visualizzare un certo linguaggio a design-time, update automatico delle proprieta’ localizzate dei controlli a runtime, gestione del binding anche nel code behind, la chiave per collegare la risorsa localizzata e’ composta da assembly:nomerisorsaresx:chiave. Libreria potente, una scelta obbligata se volete far uso dei file resx.
WPF application localization kit by Taggersoft: terza soluzione del gruppo, c’e’ un buon tutorial che ne spiega l’utilizzo, ma le localizzazioni devono risiedere necessariamente su di uno XAML based ResourceDictionary e non e’ cosi’ potente come le precedenti.

Personalmente per le mie applicazioni WPF utilizzero’ la libreria di SeriosM, con qualche piccola modifica, in modo da avere le traduzioni residenti sul db e poterle cosi’ gestire in maniera molto flessibile.

CONCLUSIONI

La trattazione dell’argomento non puo’ essere esaustiva, dato che nuovi pattern possono essere implimentati a secondo dei propri bisogni. Voglio comunque segnalare alcuni strumenti che possono aiutare in questo compito, come ad esempio RGreatEx, un plugin a pagamento per Visual Studio che identifica le stringhe di testo e ne fa il rafactoring in file di risorse, controlla inoltre se sono state localizzate per tutte le lingue, traduce automaticamente una stringa appoggiandosi su servizi online e molto altro. Oppure un breve snippet di codice per accedere ad una risorsa in una satellite dll: How to: Access Resources in Satellite DLLs.

Purtroppo però non sembrano del tutto morti e sepolti, anche perchè hanno dalla loro uno streminato partimonio di software binario scritto proprio in COM, e la loro riprogettazione per .NET si puo’ rivelare un spesa non banale da affrontare.

Ecco perchè risulta utile, delle volte, realizzare dei wrapper che permettano di utilizzare questi controlli anche all’interno di applicazioni .NET, procrastinando magari il giorno in cui veranno sostituiti del tutto e realizzando nel frattempo, grazie alla OOP, un buon layering delle proprie applicazioni, cosi’ quel giorno non fara’ poi tanta paura, Murphy permettendo. Ma anche la possibilita’ di usare fiammanti controlli .NET in vetuste applicazioni COM-enable ha il suo fascino, potendo cosi’ aggiornarle un pezzo alla volta, riutilizzando poi buonaparte del lavoro fatto.

Le tecniche di programmazione che studiano queste tematiche vanno sotto il nome di “.NET COM Interoperability”, ed hanno lo scopo di realizzare dei Runtime-Callable Wrappers (RCW: COM -> .NET) e dei COM-Callable Wrappers (CCW: .NET -> COM). Viene anche affrontato come gestire gli eventi e i dati di ritorno generati dal controllo inglobato.

How to call a Visual Basic .NET or Visual Basic 2005 assembly from Visual Basic 6.0: come usare controlli .NET in applicazioni COM, quelle classiche di Visual Basic 6.

.NET Interoperability: COM Interop: un’esauriente trattazione di Brian Long sulla creazione di RCW e CCW.

COM Interop in VB.NET: La sezione sulla COM INterop di VB.Net Heaven, con diversi articoli interessanti.

Visual Basic & .NET Journal, edizione italiana, numeri 69 e 71 del 2006.

Troubleshooting .NET Interoperability: ovviamente problemi e casi particolari ci sono sempre!

BUG: “InteropServices.COMException” error message occurs when you pass ByRef Parameters by using late binding: il titolo e’ gia’ abbastanza esaustivo.

IntelliSense Features Do Not Appear in Visual Basic 6.0 for .NET COM Interop Components : ancora qualche suggerimento per risolvere problemi comuni.

Improving Interop Performance: consigli utili su come miglioare le performance quando si ha a che fare con RCW, occupazione di memoria, early e late bindin.

Buon reciclo di codice, a questo punto!

Tutto fattibile e semplice utilizzando il metodo .ToString(), se non che l’altro programma , quello che doveva leggere i dati, aveva delle impostazioni regionali (Regional Settings) diverse dal programma che salvava i dati. Le date erano nel formato mese/giorno/anno sul primo, giorno/mese/anno sul secondo, i numero avevano come separatore decimale il punto sul primo, la virgola nel secondo. Le conversioni quindi sballavano tutte.

Ho risolto forzando il salvataggio e la lettura in un formato unico, ecco come.

Salvataggio dei dati:

double dblAmount;
string[] arrTextToSave;

System.Globalization.CultureInfo ci = System.Globalization.CultureInfo.CurrentUICulture;
objFormatProvider = (System.Globalization.NumberFormatInfo)
ci.NumberFormat.Clone();
objFormatProvider.NumberDecimalSeparator = ".";

arrTextToSave new string[2] { DateTime.Now.ToString("yyyy/MM/dd"),
dblAmount.ToString(objFormatProvider) };

DateTime dtTransactionDate;
double dblAmount;

dtTranscationDate = Convert.ToDateTime(arrTextToSave[0]);
dblAmount = Convert.ToDouble(arrTextToSave[1], _objFormatProvider);