Queste riflessioni derivano da due precedenti scoperte. La prima è la constatazione che i pur "nobili" VSTO (Visual Studio Tools per Office System) NON supportano intrinsecamente le funzioni d'utente (UDF, User Defined Function), per cui chi le gradisce non può far altro che ricorrere a Function definite in ambito VBA (Visual Basic per applicazioni).
La seconda scoperta, personalmente recente, l'ho esternata nel mio precedente post:
http://blog.shareoffice.it/giannigiaccaglini/archive/2008/09/15/9685.aspx
ove mostro che le macro presenti in Normal.dot sono disponibili in tutti i documenti aperti (di una data workstation o, credo, su un Word residente su server).La faccenda, ribadisco, è di una certa importanza laddove interessano funzionalità di impiego ricorrente. Presto ne fornirò un'applicazione piuttosto avanzato, relativa alla conversione di numeri in lettere (esempio:
1.250 --> milleduecentocinquanta) che il mio richiedente desidera poter disporre in tutti o quasi i suoi documenti.
Orbene andando a vedere cosa offrono al riguardo i VSTO, la non sorpredente (a ben riflettere) risposta è nada de nada. Scopo primario dei modelli sviluppato coi VSTO è farne delle applicazioni, il cui codice oltre che molto più versatile e potente (*) rispetto a quel che offre il vecchio mondo VBA.
(*) Formidabile, nell'ultima edizione Visual Studio 2008, il supporto di LINQ per le query "dichiarative"
delle più svarate fonti dati!
Ma se si desiderano funzionalità operanti su qualsiasi documento? In un primo tempo nasce il sospetto che un modello creato coi VSTO non lo consenta... Tranquilli però, perché se abbiamo predisposto le macro che ci stanno a cuore nel Normal.dot queste sono fruibili, automaticamente, quando si apre un qualsiasi modello Word realizzato coi VSTO.
Commenti
Distinguerei i due casi. Per quanto riguarda le UDF non riesco a capire cosa abbia impedito (salvo i tempi tecnici e una perdurante sottovalutazione) di fornirene un'implementazione "nativa". Invece con le macro di Normal.dot sono fermamente convinto (e i più, se riflettono, mi daranno ragione) che l'architettura stessa dei VSTO non permetterà mai tale supporto.
La conclusione? Sta nel titolo di questo post. Ovvero la ricorrente voce di una futura eliminazione del popolare VBA è priva di fondamento: non solo provocherebbe la rivolta delle migliaia di Power User (che oltre a trovarsi in difficoltà concettuali coi troppo "paludati" VSTO, di fatto NON ne dispongono, mentre VBA è sempre sottomano) ma per un paio di motivi il VBA resta utile e addirittura indispensabile anche nei modelli implementati coi VSTO.
O no?