Forse ora è il momento di considerare se VBA è qualcosa che dovresti desiderare. Capisco che può essere utile in alcuni casi, ma a volte c’è una soluzione migliore. Oltre ad essere estremamente pericoloso, VBA è un linguaggio morente. Gli sviluppatori che devono mantenerlo diventeranno sempre più rari e la maggior parte dei programmatori non vorrà usarlo:
- L’editor è terribile (non oso chiamarlo IDE);
- Il debug è un dramma (gli errori sono sfocati e gettati da qualche parte in fondo allo stack di chiamate, rendendo quasi impossibile trovare l’origine dell’errore in una grande base di codice);
- Controllo della versione? No! Il codice VBA è memorizzato in uno strano markup e incorporato nel documento. Puoi mettere il documento nel controllo della versione ma questo non ti mostra le modifiche apportate in nessun commit/check-in, la tua unica opzione è esportare tutti i file in una cartella e metterli nel controllo della versione;
- Il futuro è incerto, il runtime (msvbvm) per Windows 98 (!) è stato sviluppato e mantenuto al massimo per funzionare su versioni recenti di Windows ed è molto probabile che un giorno MS staccherà la spina. Come sviluppatore, non vuoi scommetterci.
Ci sono delle alternative, ad esempio è del tutto possibile sviluppare un programma in C# che può essere utilizzato per eseguire operazioni sui documenti di Office. SDK OpenXML ufficiale È open source e se vuoi fare cose con i fogli di calcolo lo è Chiuso È altamente raccomandato. L’unico inconveniente è che non è possibile aprire documenti quando si desidera eseguire operazioni con il programma C#.
Puoi anche farlo Non Ma temo che prima o poi ti imbatterai in problemi: se Microsoft estrae componenti su VBA, e questo sta per accadere, dovrai cercare sviluppatori dell’ultimo minuto che devono convertire tutto in .C# .
