Version imprimable
Bonjour a tous,
Je developpe pas mal d'appli de stat en c# et en windev.
Pour moi le VBA est une bénédiction pour mettre en forme les données en pilotant Excel.
Et puis j'aiu des appli VBA qui tourne et franchement pas mal,
dans la durée, une telle stabilité je ne l'ai vu que dans C#.
Après il faut un peu structurer son code...comne d'hab quoi !
Sujet intéressant
Pour moi VBA, c'est le couteau suisse de l'informatique. J'ai appris ce langage, j'ai de vague notions dans les autres, et j'avoue j'ai beaucoup de mal à rentrer dans les autres langages.
Déjà en VBA, il faut savoir qu'on peut encapsuler des instructions de n'importe quel autre langage, je peux donc lancer une requête SQL sur une table, je peux faire du data-mining sur des pages web, lancer des requêtes en Javascript, JSON, mais également fait des RDN sophistiqués
VBA permet, avec certes moins d'efficience que les langages spécialisés, de toucher à plein d'aspect de l'informatique, datamining, interface web, interface utilisateur
J'ai fait des applications en vba, où l'utilisateur ne savait même pas qu'il utilisait excel
Appel de la userform depuis un vbscript, transformé en .exe avec un vbs2exe... une petite icône pour faire joli, ça ressemble à un executable comme un autre, qui ouvre une fenêtre comme une autre
Pour le cousin VB6, c'est pareil, on fait des applis, certaines sont crades et d'autres particulièrement chiadées.
VB.NET et C# sont des neveux tout ce qu'il y a de professionel, et leur syntaxe a beaucoup en commun avec le VBA.
Enfin je pense que c'est dommage de limiter l'informatique aux seuls services IT d'une grande boîte. L'informatique c'est également l'algorithmique, et sans parler de la frontière entre science et informatique (que ce soit mathématiques appliquées, physique, chimie, bio, finance, géo, etc...) La plupart des métiers scientifiques nécessitent de tester des modèles, et VBA apparaît à ce titre comme un auxiliaire précieux
VBA est majoritairement utilisé par des professionnels non professionnels de l'informatique. A ce titre, ceux ci sont susceptibles de faire des erreurs de débutant, et de passer à côté de nombreuses fonctionnalités intéressantes.
Je m'intéresse à d'autres langages que VBA, parce qu'il y a forcément des limites à ce langage. Quand on veut faire des choses un peu plus bas-niveau, travailler avec les librairies, faire de l'administration réseau, etc ça devient compliqué.
Au final VBA est un langage qui n'a pas à rougir par rapport à la majorité des langages (si on met la question des performances de côté). Par contre, il est vrai qu'il est majoritairement utilisé par des non informaticiens, pour les raisons évoquées plus haut (coût et délai d'une intervention IT, souplesse de MAJ des applis VBA car tt le monde sait faire du VBA)
au final ce qui manquerait à VBA c'est les packages et librairies permettant de prolonger ses aptitudes, on pourrait penser à des sorties graphiques, à de l'OCR, etc... dès qu'on veut sortir un peu des clous de l'automation Office, il faut pédaler dans des API peu documentées, mais j'imagine que c'est un peu le même lot des autres langages.
Gorz
Ouais, mais des fois, à force de faire des guerres de clochers, extrêmement ennuyantes pour la plupart des membres, sur la façon de programmer en VBA des recherches récursives de fichiers, alors qu'il n'a jamais été conçu pour cela, on se pose des questions...
Bonjour clementmarcotte
:plusser:
Je "plussoie" d'autant ta remarque, que :
- la résolution de ce "problème" (au demeurant parfaitement résoluble avec VBA) nécessite beaucoup plus une bonne connaissance de Windows
- VBA offre déjà ce qu'il faut à des fins réellement utiles ("passer" sur une feuille de calcul une arborescence ne sert pas à grand-chose, pour ne pas dire "ne sert à rien")
- il est assez dangereux, par contre, de faire un "outil" bancale, incomplet, etc ... en lequel un néophyte pourrait ingénument confier
- s'il s'agit de faire l'examen (très sporadique et dans des circonstances très particulières) de ce que l'on a : l'explorateur est là pour cela
Amitiés
j'ai du mal à saisir cette question de l'utilité de récréer une arborescence de fichiers
si je reçois un paquet de dossier et sous dossiers bordéliques avec des milliers de fichiers, le premier truc que je fais c'est de tout lister dans l'arborescence, les extensions, les tailles de fichiers, le lastmodified, etc... et vba est effectivement le plus efficace que je connaisse pour se faire une idée rapide de ce que contient un dossier, mais bon ça c'est un pouillème des possibilités de vba, qui au passage peut encapsuler des requêtes dans n'importe quel autre langage
la principale difficulté de vba c'est d'appréhender l'immensité des possibilités qu'il ouvre, à ce titre c'est pour ça que je l'appelle couteau suisse de l'informatique.
Je n'ai jamais compris non plus comment on peut affirmer de façon si péremptoire que
La vie quotidienne dans une entreprise est tellement semée de surprises que dire "... ne sert à rien" m'apparaît comme risible (ce n'est pas une attaque ad hominen, ucfo... heu unparia) et, comme le fait remarquer Gorzyne, il est parfois bien utile de récupérer une arborescence de dossiers dans une feuille Excel.Citation:
Envoyé par unparia
J'ai notamment dû, lors d'une migration Office 2003 => Office 2013, proposer une analyse quantitative des fichiers présents sur un réseau (plus de 100.000 fichiers) avec + de doc, xls, pdf, ... Ben, plus rapide que VBA pour créer la liste et qu'un TCD pour l'analyser, je n'ai pas encore trouvé...
Pour le scripting pur, je m'autorise a accelerer le traitement de listing des fichiers avec du python, mais l'analyse reste evidemment des plus efficace sous Excel ou Access selon les besoins :)
Bonjour
Je crois alors utile d'être beaucoup plus précis :
1) Ce qui, dans ce genre d'affaire est essentiel n'est pas l'affichage ici ou là, sous telle ou telle autre forme, mais la constitution de ce que l'affichage va utiliser (que ce soit une matrice, une base de données, une collection, etc ...)
2) Le reste (le choix du support de l'affichage) est ensuite très simple, lui, si la constitution citée en 1) a été bien pensée.
Je suis en train de commenter (lourd et patient travail que je ne fais que pour que l'on puisse tout suivre) un outil que j'ai terminé sous VBA. On pourra y constater l'importance de ce que j'ai exprimé en 1)
Amitiés
Bonjour
J'adhère complètement à la réponse de Pierre FAUCONNIER.
Mon expérience personnelle a été de 14 ans en informatique et 20 ans dans un service Administration du personnel. Quand l'informatique peut répondre avec des applications verticales aux fonctionnalités nécessaires tout va bien.
Mais il arrive souvent qu'un fonctionnalité n'est pas couverte par l'éditeur et/ou que les besoins de l'entreprise en terme de reporting nécessitent des compléments. Là aussi il faudrait attendre des lustres pour que le besoin remonté puisse être intégré dans un plan d'évolution.
Et c'est là que le "professionnel" métier peut se faire des outils adaptés pour pallier le manque. Même si VBA est banni par l'IT, développer un modèle Excel reproductible à loisirs à partir de requêtes issues du SI apporte une solution très confortable et adaptée qui a le mérite de maquetter le besoin; et souvent ce palliatif va rester longtemps !
Alors OUI Excel en utilisant, les modèles (XLT, XLTM), les modules de classes, et donc le VBA peut s'insérer parfaitement dans un SI digne de ce nom, j'en ai une expérience de 13 ans.
Bertrand
Bonjour blepy
Tu veux parler de quoi, exactement ? :
1) d'une entreprise qui n'aurait que Office et VBA ?
ou
2) d'une entreprise qui aurait d'autres outils de développement mais dont les employés/informaticiens ne se focaliseraient que sur VBA/Excel pour obtenir ce recensement de fichiers ?
Bonjour
C'est un gros dilemme cette question
D'un coté la capacité de VBA pour créer des applications super productives en 4 clics est juste phénoménale.
D'une autre coté le VBA est juste le langage le plus pourri du monde, je ne connais pas des tonnes de langages mais quand je fais du VBA aprés du C le C# (que je pratique régulièrement) je prends des crampes.
Je me souviens avoir lu à de nombreuses reprises que le VBA était un langages pour les nuls, c'est archi faux : VBA autorise de coder en définissant mal pleins de trucs, il "tolère" et "devine" ce que l'on a saisi jusqu'à ne plus réussir à deviner et paf ça explose. Il demande une grande rigueur de programmation comme tous les langages sauf que dans les autres cette rigueur est imposée !
En plus le VB est super verbeux.
Excel et Access avec un langage de qualité (genre du C#) ce serait tout simplement énooooooorme ! Si ça pouvait permettre de faire des formulaires et états d'impression moins moches et plus adaptatifs là ce serait carrément génial.
Bref, vendre une application développée sous Access VBA par exemple, c'est pas sérieux, j'en ai connu une à mon boulot (un truc de gestion de la métrologie sur des appareils de mesure), c’était vraiment nul, à la fois moche et pas ergonomique bien que ultra chiadé pour du Access+VBA.
Mais pour développer des outils internes en mode AGILE c'est top et très pro puisque très productif.
Bonjour petitours
Je pense que tu as bien "noté" la section (VBA EXcel) de ce forum dans laquelle a été ouverte cette discussion ...
Aucun problème (ni éthique, ni autre) si l'on s'en tient à ce qu'est la vocation d'un T A B L E U R. On peut a contrario se poser un très grand nombre de questions sur l'efficacité, la légitimité et les performances atteintes par ce que l'on ferait depuis VBA/Excel en détournant Excel de sa vocation.
Il ne me viendrait par exemple pas à l'esprit (ni même une seule seconde) d'utiliser un tournevis pour pratiquer (en le manipulant, lui assénant des petits coups de marteau, lui faisant subir des rotations, etc...) un trou dans quelque matériau que ce fût, hein ...
A contrario, la plupart (pour ne pas dire la quasi totalité) des applications non-tableurs ne sauraient faire aussi agilement ce que sait faire un tableur pour traiter aussi prestement des calculs (et leur présentation) que saurait le faire un tableur (Excel ou autre).
A chacun son métier est un dicton bien connu. A chaque logiciel sa vocation serait ici un dicton de même nature et plein de vraie sagesse. ;)
Bonjour
Oui et non. Quand on regarde l'arbre généalogique de VBA, l'ancêtre c'est le BASIC, un langage qui devait être une sorte d'intermédiaire dans l'apprentissage du Fortran. C'était fondamentalement un langage qui était utilisé sur terminal et même sur des terminaux à imprimantes au bouts de lignes téléphoniques ordinaires, sans gestion d'erreurs qui décrochaient souvent. Et évidemment sans capacités graphiques, sauf l'affichage des caractères ASCII; le code original à 128 caractères. Microsoft, et quelques autres sociétés, ont pris ce langage-là pour le porter sur des micro-ordinateurs. Microsoft a pris sa version pour l'adapter plus tard à Windows et créer Visual BASIC. Puis Microsoft a eu l'idée d'abandonner les macros Excel et les macros Word et la nécessité de créer un langage macros pour les autres applications Office, pour les remplacer par une version de Visual BASIC adaptée aux applications Office, et aussi disponible pour les sociétés qui voulaient acquérir la licence pour l'utiliser avec leurs propres produits. En prime, ils ont voulu "convertir" un produit qui ne connaissait rien de la programmation-objet en langage (supposément, ou partiellement, objet)Citation:
Envoyé par petitours
Ça, c'est un héritage du BASIC d'origine. Pour faciliter la vie et l'apprentissage, les auteur d'origine ont abandonné la conversion explicite des types de données (qui n'étaient pas des objets) pour la remplacer par un mécanisme de conversion implicite qui peut vraiment causer des surprises.Citation:
Je me souviens avoir lu à de nombreuses reprises que le VBA était un langages pour les nuls, c'est archi faux : VBA autorise de coder en définissant mal pleins de trucs, il "tolère" et "devine" ce que l'on a saisi jusqu'à ne plus réussir à deviner et paf ça explose.
Mais tu peux facilement, ou relativement facilement, développer des applications Office à partir de C#. Ce n'est pas vraiment l'endroit pour élaborer, mais rien ne t'empêche de poser la question dans les forums .netCitation:
Excel et Access avec un langage de qualité (genre du C#) ce serait tout simplement énooooooorme ! Si ça pouvait permettre de faire des formulaires et états d'impression moins moches et plus adaptatifs là ce serait carrément génial.
Tu peux aussi utiliser Word pour réaliser tes rapports en partant d'Access...
Bonjour
Le langage VBA n'est pas très évolué (une gestion des classes OO assez basique; pas d'héritage, surcharge, ...), syntaxiquement peut mieux faire (la rigueur n'est pas son point fort), ... Oui, on peut le critiquer à juste cause aussi parce qu'il n'évolue plus. Je fais du VBA régulièrement depuis vingt ans et le langage est resté le même.
Cela étant, j'aime et j'apprécie le VBA. On peut tout faire ou presque...
Actuellement, je travaille sur un besoin de gestion de contacts : savoir qui travaille où et avec quelle rôle. Une même personne peut travailler / être responsable dans différentes sociétés et, au sein d'une même société, avoir différentes casquettes. On pourrait nommer cela un CRM; léger bien sûr mais c'est l'idée. Qui, où, quelle fonction, quelles permissions logicielles, ...
Mon point de départ : développer l'interface en SharePoint car il faut un accès web à l'information.
Toutefois, la gestion des données (ajout, édition, suppression) dans SharePoint, bof bof. Ok pour éditer un seul record au travers d'un formulaire natif mais si on veut éditer plusieurs enregistrements, mouais, bof.
Et là, Excel et VBA, viennent à la rescousse : les listes SharePoint deviennent des feuilles de calcul avec une connexion dynamique. Un petit "Refresh" et hop, c'est mis à jour. L'interface VBA permet de créer un ruban => j'y mets des boutons "Add", "Delete", "Submit", ... et tout se fait en VBA. Je modifie, ajoute, supprime, je tire des formules, je fais des mises-à-jour automatisées, ... et "Submit" envoie tout sur SharePoint grâce à des appels REST.
Alors, oui, après vingt ans, je reste convaincu que dès lors qu'il faut travailler des données tabulaires et peu importe où sont stockées les données (txt, database, web, ...), Excel & VBA est une excellente solution.
POO basique, tout dépend des critères:Citation:
Envoyé par cavo789
- Pas d'héritage (en tant que tel), c'est vrai, mais on peut pallier certains problèmes du manque d'héritage en créant un pseudohéritage en VBA de façon simple et pratique;
- Pas de surcharge, c'est vrai, mais les paramètres optionnels permettent de pallier ce manque dans une certaine mesure.
Je rappelle que les objets créés peuvent interfacer ou être interfacés, ce qui permet un certain polymorphisme.
Pour le reste, je te rejoins assez dans les appréciations que tu fais du langage et de ses possibilités.
Je rappelle également que VBA ne se limite pas à Excel, et que même si la discussion est dans un forum Excel, rien n'empêche de sortir largement du cadre Excel. VBA est très efficace pour créer des applications professionnelles robustes, avec Excel bien sûr, mais aussi avec Access, Word et autres. Je réalise régulièrement des applications VBA qui utilisent conjointement Access, Excel et Word.
Bonjour,
Je ne suis pas développeur. Et sur mon poste de travail, je n'ai rien qui permet d'aligner des lignes de codes autre que VBA.
Pour les informaticiens et développeurs, c'est évident que VBA est du bricolage quand c'est fait par des gens comme moi.
Et c'est indiscutable; cependant, bricoler de la sorte me permet de gagner du temps dans mon travail en automatisant des tas de trucs que je devrais faire à la mano...
Tout ce qui est traitement répétitif est faisable efficacement avec VBA et tant mieux, et quand on lit les conseils des développeurs sur les forums et qu'on cherche à comprendre ce qu'on fait, le résultat est pas si pourri et fonctionne correctement.
De toute façon, si je ne le développe pas moi-même avec VBA, je n'ai rien car le service informatique plein de pros n'imagine même pas perdre son temps avec des petits besoins comme les miens ...
Lorsqu'on a pas d'outil pour ouvrir une boite de petit pois (cf le tout début de la discussion), on prend ce qu'on a sous la main et si on est pas trop con, on y arrive avec une fourchette et au bout de 10 boites ouvertes, on le fait aussi bien qu'avec un ouvre boite ... on s'adapte à ce qu'on a.
Concrètement, pour répondre à la question de départ, ma réponse est oui puisque ça me permet de faire des petits outils et autres utilitaires pour me faciliter la vie au travail, et celle de mes collègues dans le milieu professionnel ...
En fait, toute l'ambiguïté d'une question comme celle de cette discussion repose sur le fait que nous avons tous des grilles de critères différentes pour répondre, qu'aucun n'a LA bonne et nous n'arriverons jamais à mettre tous les intervenants d'accord sur la grille de critères à utiliser.Citation:
Envoyé par Ldntech
Et le critère que tu soulignes à la fin de ton message est un des miens, si pas le mien, pour, comme toi, répondre OUI à la question.
Pourquoi est-ce contre-productif? J'ai écrit en VBA un logiciel complet de gestion des impacts environnementaux (FGIE pour Fichier de Gestion des Impacts Environnemtaux) en entreprise avec Excel comme outil de stockage de données. Ce fichier fonctionne dans une petite centaine de sociétés différentes, pour le plus grand bonheur des auditeurs externes qui connaissent l'outil et qui peuvent s'appuyer dessus pour certifier les entreprises en ISO14001.Citation:
Envoyé par Omote
Ce logiciel aide donc des entreprises à progresser dans la qualité. Qu'y a-t-il de non professionnel dans la démarche? Excel était imposé comme support pour différentes raisons, et Excel+VBA ont permis de créer un outil professionnel s'inscrivant dans une démarche professionnelle. J'attends celui qui arrivera à me démontrer le contraire.
Et cette démarche a été possible parce que VBA permet le développement d'outils professionnels, et donc il est un langage professionnel.
En train de développer un ERP sur une structure Access (frontal), classes personnalisées et dal en VBA, MS-SQL pour les données et procédures stockées...
Qui a dit qu'on ne faisait pas du pro avec VBA? ;)
Bonsoir,
https://www.developpez.net/forums/d1...l/#post8938804
Microsoft a volontairement bridé vb6 pour éviter que vba devienne un langage de programmation professionnel
Ne soyons pas plus royaliste que le roi et convenons que Microsoft nous classe dans la catégorie des bidouilleurs professionnel!