Discussion :

[shkyo]

Bonjour à tous,

J'aurais besoin de vos conseils, depuis quelques temps je développe des macros en VBA sous Excel avec l'éditeur intégré qui est... comment dire... un peu archaïque!
Je veux dire par là que mes macros sont assez "touffues", la dernière en date représente dans les 2500 lignes de code, la précédente faisait dans les 4000 lignes, bref ce sont presque des minis applis.

Comme j'ai aussi une licence Visual Studio Pro (2010), je me demande si je ne devrais pas plutôt développer des Add-ins pour Excel, et ainsi pouvoir utiliser un EDI (beaucoup) plus moderne!

Mais je n'ai jamais développé d'Add-in, qu'est-ce ça a comme contrainte pour l'utilisateur final?

Merci d'avance!

[Marc-L]

Bonjour,

en passant le nombre de lignes n'a rien à voir avec la modernité ressentie de l'éditeur
mais découle tout simplement de la conception de l'auteur du code !

Sur ce forum j'ai vu des usines à gaz de 180 et 300 lignes
alors qu'un code respectivement de moins de 30 et 50 lignes remplissait le même office !

Le développement d'Add-In a un intérêt certain en terme de sécurité (protection intellectuelle)
et de rapidité car le VBA n'étant qu'un langage interprété …

La contrainte : être vraiment rigoureux !

_____________________________________________________________________________________________________
Je suis Charlie - Je suis Bardo

[shkyo]

Tout à fait d'accord sur le nombre de lignes! Je précisais ça juste pour dire que ce ne sont pas des macros qui font trois bricoles, elles font un nombre conséquent d'opérations.

La partie propriété intellectuelle peut être intéressante pour ma boite effectivement. Mais comment livre-t-on ça à un utilisateur, ou un client, c'est une install au final?

Et côté compatibilité ça donne quoi? Un add-in fait en version 2010 (c'est les versions VS et Office de mon pc) va-t-il fonctionner sous 2007, ou sous 2013??

Désolé de toutes ces questions, je n'ai jamais utilisé les add-ins...

[Invité]

Bonjour,
Plus moderne, tu parle comme un vieux! Ou un trop jeune! IDE de visual studio 2013 par exemple est loin d'être plus moderne!

Ses possibilités et ses performances sont incomparables certe mais dans vba tu as des modules de classe comme dans. Vb.net il n'y a pas de surcharge d'héritage n'y de polymorphisme, mai ses possibilités sont tout à fait honorables.

Vb.net peut gérer ton projet de bout en bout! Pourquoi ne pas le faire en VB.net?

[shkyo]

Ni vieux, ni jeune, j'ai 41 piges...

Pourquoi pas tout en VB.net? Deux raisons, la 1ère c'est que je n'ai pas toujours le choix, parfois c'est VBA sous Excel et rien d'autre! Et la 2ème raison, c'est la gestion de l'ouverture/fermeture des entités excel en mémoire, j'ai souvent vu que c'était problématique (Excel qui ne se ferme pas, ou qui est déjà ouvert, et ça plante ou ne fonctionne pas). J'ai eu moi-même des soucis avec ça, mais après je m'y suis peut-être mal pris...

Mais sinon, du VB.net complet je suis pour à 100%!

En fait, la plupart du temps, j'ai un certain nombre de données d'entrées, souvent du fichier au format texte, ou .csv, ou Excel, qu'il faut que je traite et mouline, et dans 99% des cas, cela doit sortir sous forme de classeur Excel multi-onglets.
C'est pour ça que je me pose la question des add-ins Excel...

Qu'en penses-tu?

[Zirak]

Bah au final, vu qu'un add-ins ne rendra pas tes macros moins touffues, et qu'il ne reste donc que la question de ton confort de développement entre l'éditeur VBA ou l'IDE VS, on ne peut pas trop te conseiller ce qui est le mieux pour toi.

Après le truc des add-ins, c'est que du coup, tu passes de 1 fichier à plusieurs (ton classeur + ton add-ins), add-ins qui doit être dans un dossier bien spécifique il me semble et présent sur le poste de chaque utilisateur.

Pour moi, si passer sur des add-ins ne t'apporte rien au niveau des performances de ton développement même, tu vas juste t'ajouter la contrainte de devoir déployer / tenir à jour 2 fichiers au lieu d'un.

[shkyo]

Perso, c'est clair que je te préfère l'IDE de VS2010 à celui de VBA...

C'est vrai que gérer les 2 fichiers ça peut être un frein, faut voir à l'usage.