Creazione del progetto .NET di base

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

Continue reading ‘ComInterop in C# e VB.NET’ »

I “vecchi” controlli realizzati usando dal tecnologia Microsoft COM (Component Object Model), hanno sicuramente cavalcato gli incubi di molti programmatori, fino a creare quell’universo di dolore parallelo chiamato DLL Hell, ben noto a chi ha sviluppato con Windows 95, 98, ME, NT, 2000 e forse forse anche XP. Insomma, prima dell’introduzione del .NET Framework.

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.

Continue reading ‘Usare controlli COM in .NET’ »

Mi e’ capitato di dover salvare alcune informazioni, contenenti numeri e date, in un file di testo per poi rileggerle con un altro programma.

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) };

Continue reading ‘Conversione di date e numeri location aware’ »

Nella programmazione, soprattutto quando si tratta di usare framework evoluti come può essere il .NET, ci sono stupidate che però fanno perdere anche ore di scervellamenti vari.

E’ il caso del datamapping, più specificatamente il datamapping di una GridView. Infatti questo potente controllo permette di crearsi più stili da usare al momento opportuno per cambiare a volo la visualizzazione dei dati dell’oggetto bindato, senza scrivere tonnellate di codice. Ogni stile però va collegato ad un oggetto al quale verrà applicato tramite la proprieta’ DataGridTableStyle.MappingName. Nel caso in cui alla DaraGrid sia bindata una DataTable o un DataSet pochi problemi, basta specificare il nome della Table da visualizzare. Ma se viene bindato ad una Collection, List o un proprio oggetto che implementa l’intefaccia IList, che cosa bisogna mettere?

Continue reading ‘Impostare correttamente il MappingName del DataGridTableStyle di un DataGrid’ »