Voir le flux RSS

clementmarcotte

Pourquoi utiliser Excel (ou même Office) avec VB.net

Noter ce billet
par , 01/10/2019 à 01h33 (413 Affichages)
Puisque je viens enfin de réussir à mettre une partie de mes exemples de VB.net, je peux commencer mon plaidoyer ici. Pourquoi VB.net en plus, ou même à la place de VBA. Tout d'abord, parce que VBA est, tout comme VB6, un vieux langage. Depuis de nombreuses années, les seules modifications apportées à VBA l'ont été pour suivre l'évolution d'Excel, Word, PowerPoint et, je présume, d'Access. Et je sais que VBA a été intégré à Publisher. Parallèlement à cela, Microsoft a autorisé d'autres entreprises à utiliser VBA pour leurs propres produits.

Depuis de nombreuses années, Microsoft a doté Visual Studio des outils permettant à VB.net (et même C# et tout autre langage inclus dans Visual Studio) des outils pour programmer les applications Office; au début sous le nom de Visual Studio Tools for Office et aujourd'hui sous le nom de Office Tools pour Visual Studio. Si ces outils sont indispensables dans certaines circonstances, il existe de nombreuses situations où il est parfaitement possible de s'en passer.

Et, de toutes évidence, Microsoft n'a plus grand intérêt pour VBA et même VBScript. La nouvelle API de Microsoft pour la programmation d'Office (Depuis Office 2013) est basée sur JavaScript, même su elle supporte d'autres langages, incluant Python. Grâce à longue volonté de Microsoft de préserver la compatibilité, VBA continue d'être supporté dans Office.

Parallèlement, l'évolution de VB.net à suivi celle du Framework.net et a vu s'ajouter des éléments, comme Linq (et les méthodes d'extension et les fonctions Lambda), (admettons qu'Excel a quand même eu droit à PowerQuery, comme "passerelle" pour interroger PowerBI et utilisable à d'autres fins), le support des PC à plusieurs cœurs, le support intégré de la compression au format zip et le présume qu'il a toujours celui du format gz qui était là avant zip et la capacité de créer directement des fichiers Office Open XMl (Office 2007 et après). Et pour Excel, Word et PowerPoint, le SDK Open XML, permet de simplifier, au moins un peu, le processus. Admettons que c'est toujours plus facile à partir des applications Office elles-mêmes. Et depuis une éternité, VB.net est multi-tâches et supporte les threads et la programmation asynchrone. Et VB.net, le Framework.net, en fait, supporte déjà depuis plusieurs années les procédures récursives plus simplement que VBA.

Également et je dis même surtout, l'édition des programmes est beaucoup plus agréable. L'Intellisence préhistorique de VBA a fait place à une Intellisence moderne qui aide beaucoup plus à l'édition de programmes. Maintenant, je persiste et je signe : VB.net et Office ne sont pas des chimères. Ce sont des associations aussi naturelles et même meilleures que les associations de VBA et Office. Mais, il y en a toujours qui ne penseront a qu'à nier l'évidence.

Envoyer le billet « Pourquoi utiliser Excel (ou même Office) avec VB.net » dans le blog Viadeo Envoyer le billet « Pourquoi utiliser Excel (ou même Office) avec VB.net » dans le blog Twitter Envoyer le billet « Pourquoi utiliser Excel (ou même Office) avec VB.net » dans le blog Google Envoyer le billet « Pourquoi utiliser Excel (ou même Office) avec VB.net » dans le blog Facebook Envoyer le billet « Pourquoi utiliser Excel (ou même Office) avec VB.net » dans le blog Digg Envoyer le billet « Pourquoi utiliser Excel (ou même Office) avec VB.net » dans le blog Delicious Envoyer le billet « Pourquoi utiliser Excel (ou même Office) avec VB.net » dans le blog MySpace Envoyer le billet « Pourquoi utiliser Excel (ou même Office) avec VB.net » dans le blog Yahoo

Tags: macros, office, vb.net
Catégories
DotNET , VB.NET

Commentaires