Pourquoi penser que son code VBA est le programme en soi ?

bonjour

avez-vous remarqué combien de questions sur ce forum son posée sous cette forme :

"j'ai un bug dans mon VBA. Vous trouverez ci-dessous le code"

et on lit le code dans le message, mais aucun fichier n'est joint !

mon impression : les utilisateurs font du code pensant que ce code peut vivre en dehors du fichier Excel où il agit,

comme si on pensait qu'un coeur pouvait se soigner en l'enlevant du corps, on le passe à un AUTRE chirurgien qui 'examinae, le soigne puis le repasse au premier qu ile réintégre dans le corps,

bon, j'évite VBA, mais si on le maltraite à ce point, je n'ai plus besoin de l'éviter. Il évitera lui-même d'être soigné. Et mourra tout seul.

Dites, vous les experts en VBA, défendez les bonnes formations à VBA.

je le dis en toute amitiés

comme vous j'aime Excel et n'aime pas qu'on en fasse mauvais usage.

bon travail à tous

bonne journée

Hello Jmd,

Sur certains forums, c'est le contraire d'ici, les fichiers sont plutôt rejetés par les intervenants réguliers, à cause du risque de code virus, piège, ... Mais bon ce n'est pas la justification première.

merci de ta réponse

dès lors comment répondre à une question sur une macro ?

quelle est la justification première ?

Bonjour,

Simplement pousser le demandeur à faire une explication correcte, complète et claire.

A lui de faire l'effort d'être compris. Exit les "ça marche pas".

eric

salut eriiic

bien entendu

je parle de l'état d'esprit des questionneurs

soit, comme le suggère waard, ils sont vu que joindre un fichier avec macro est interdit, et font de même ici,

soit ils considèrent que la macro est une entité à part

la question reste ouverte

bonne journée à toi et à tous

bien entendu

je parle de l'état d'esprit des questionneurs

Je n'ai fait que répondre à tes questions de 20:09

Pourquoi les avoir posées alors ? On peut effectivement se poser la question de 'l'état d'esprit des questionneurs'

eric

oui, certes

je m'étais sans doute mal exprimé

j'avais bien abordé le sujet, sans l'ouvrir toutefois

et je finissais par "vous les VBAistes experts, faites en sorte de former les débutants"

(je suis en totale contradiction avec mon opinion sur VBA, mais cohérent avec l'envie que les Excelliens connaissent bien leur outil, y compris les accessoires anciens)

note : souvent les réponses aux problèmes de macro, c'est la macro corrigée. C'est bien. Mais ça ne forme pas du tout la plupart du temps. Il vaut mieux une explication et pas de solution

le fil dérape : les questions doivent-elles recevoir une réponse sèche ou bien faut-il faire de la pédagogie ?

(en VBA ou en formules comme en autres fonctionnalités)

Je suis entièrement d'accord avec toi.

Il vaut mieux apprendre au demandeur à se servir de l'outil. Beaucoup de fonctionnalités, même basiques, sont inconnues pour certains.

Mais là ça dépend du demandeur.

Au début je perdais du temps à développer les tenants et aboutissants pour voir qu'au final le demandeur s'en foutait royalement.

Tu as dû le remarquer pour un simple TCD. Parfois on va ignorer totalement ta réponse même argumentée, pour encenser celle qui oblige à lister tous les items et à mettre 5 formules dont certaines matricielles : il voulait des formules, pour lui ça y répond et ne regarde pas plus loin que le bout de son nez...

Donc maintenant le plus souvent c'est une réponse avec le minimum d'explications. A lui de manifester son intérêt s'il veut en apprendre plus. Si ce n'est pas un boulet je ne ménagerai pas mes efforts pour partager ce que je connais.

eric

Bonjour !

Je suis d'accord avec vous, il est inutile de proposer des solutions toutes faites si elles sont bêtement recopiées et incomprises. D'un autre côté, c'est vrai que certains se fichent pas mal de comprendre quoi que ce soit malgré les efforts de pédagogie.

Personnellement je pense donc qu'il n'y a pas de manière toute faite d'apporter une réponse, mais il me semble préférable de ne pas donner tous les éléments tout de suite et d'essayer d'amener à un minimum de réflexion de la part du demandeur. Ne serait-ce que sur l'organisation de son fichier, ou sur la méthode à retenir pour traiter un problème (puisque certains sont persuadés que la solution est telle formule ou une macro, etc...).

Et pour ça, il est généralement plus facile, en ce qui me concerne, de pouvoir manipuler un fichier et d'avoir un code ou une formule remise dans son contexte (à savoir un ou plusieurs fichiers avec une organisation spécifique).

Bonjour jmd, Salut à tous !

Tu soulèves un réel problème, qui repose sur le fait que (sauf exceptions naturellement, et fort heureusement il y en a ! ) les débutants en macro commencent à utiliser des macros sans même connaître ce qu'est exactement une macro... On peut repartir sur de bonnes bases dès lors que l'intéressé se sera lui-même persuadé qu'il est utile pour utiliser un outil de commencer par apprendre à s'en servir !

Et en second lieu mais c'est lié, que pour manipuler des fonctionnalités Excel avec VBA, il faut d'abord savoir s'en servir sans VBA...

Pour rester centré sur le problème posé au départ, lorsqu'il s'agit de répondre sur une erreur apparue lors de l'exécution du code, il est possible de la solutionner hors communication du fichier s'il s'agit d'une erreur de syntaxe VB... Le problème est que le demandeur n'est pas en mesure de faire la distinction...

[Je poursuivrai plus tard, on m'appelle pour partir... ]

Bonne journée à tous.

Bonjour jmd, Salut à tous !

Tu soulèves un réel problème, qui repose sur le fait que (sauf exceptions naturellement, et fort heureusement il y en a ! ) les débutants en macro commencent à utiliser des macros sans même connaître ce qu'est exactement une macro... On peut repartir sur de bonnes bases dès lors que l'intéressé se sera lui-même persuadé qu'il est utile pour utiliser un outil de commencer par apprendre à s'en servir !

Et en second lieu mais c'est lié, que pour manipuler des fonctionnalités Excel avec VBA, il faut d'abord savoir s'en servir sans VBA...

Pour rester centré sur le problème posé au départ, lorsqu'il s'agit de répondre sur une erreur apparue lors de l'exécution du code, il est possible de la solutionner hors communication du fichier s'il s'agit d'une erreur de syntaxe VB... Le problème est que le demandeur n'est pas en mesure de faire la distinction...

[Je poursuivrai plus tard, on m'appelle pour partir... ]

Bonne journée à tous.

Bonjour à tous,

Très intéressante comme question,

Je suis totalement d'accord avec M.Ferrand sur les points qu'il a soulevé, il arrive souvent que certains demandent comment faire quelque chose sous VBA avant de se demander si c'est possible sur Excel, ce qui est un vrai problème... Personnellement je ne me suis lancé sur VBA qu'une fois que je savais à peu près utiliser Excel (je ne parle pas des formules de statistique que je n'utilise jamais mais bien des formules de recherche, de manipulation de texte, les sommeprod avec des conditions, les formules matricielles, l'ensemble des fonctionnalités d'Excel...).

Pour la pédagogie je dois avouer que je fais en fonction du candidat, si je vois que le post est soigné, le problème bien expliqué, que la personne se montre intéressée, je suis plutôt prêt à expliquer et c'est parfois ce que je fais. En revanche, si je vois le contraire, je fais une réponse simple sans aller loin, parce que je me doute que la personne prendra juste le fichier et fermera la page...

Mais pour revenir sur le sujet principal, à savoir :

"les utilisateurs font du code pensant que ce code peut vivre en dehors du fichier Excel où il agit"

Si on en revient à la base du programme VBA, c'est un programme qui manipule des objets (feuilles, cellules, contrôles....), et sans voir ces objets via le fichier qui les contient, on fait des devinettes, les réponses que l'on fournit manquent de précision, voir on ne comprend pas ce que la personne nous demande car on se retrouve avec des :

If Range(machin) = truc

Et comme on ne sait pas dans quelle feuille on est, ce que contient le Range, on ne peut pas répondre de façon optimale... VBA ne peut pas fonctionner sans Excel, car il intervient dessus en permanence... Alors certes les fichiers peuvent contenir des virus, mais sans un fichier on ne peut pas travailler dans de bonnes conditions...

Bonne journée à tous

Bonjour à tous...

personnellement je me refuse de faire un fichier test pour pouvoir exécuter un code... si la personne ne peux pas donner un fichier car il contient des données confidentielles, je demande un fichier avec des valeurs bidons. mais gardant la même architecture...

le problème d'excel (ou de la suite bureautique MSO de manière générale) est qu'elle est tellement puissante que le commun des mortels l'utilise a 5% de ses capacités...(et encore je penses que je suis large...) il est très difficile d'être expert dans ces logiciels.

Maintenant il est vrai que, si on souhaite faire du VBA, encore faut-il se poser la question dans un premier temps si c'est déjà faisable avec excel seul... car a priori ton ce que l'on peut faire avec excel est "automatisable" avec du VBA.

Fred

salut à tous

fred : qu'est-ce que Excel seul ? car sa définition varie dans le temps

pour moi par exemple, sur la dernière version, Power Query et Power Pivot sont dans Excel*, alors que Power Query est aussi dans Power BI !

Excel est à géométrie variable

* ce n'était pas tout à fait vrai il y a qq années, il fallait télcharger PQuery, et PPivot était réservé aux versions chères.

Bonjour a tous

@jmd quand je parle de "excel seul" c'est sans les add-ons.. perso j'ai utilisé exclusivement la version 2007 très longtemps (à la maison et au boulot) j'ai eut accès à la version 2013 au boulot depuis 2 ans environ... et une opportunité avec le boulot de O365 depuis 4 mois...

parlant de Pquery, comme je l'ai indiqué dans un post auquel tu répondais... c'était un add-on qui est intégré aux dernières versions d'office mais il faut encore l'activer... (et donc savoir que cela existe aussi... donc pour le commun des mortels ne savent pas que cela existe...)

j'ai de la chance, car j'ai pas mal de collègues qui utilisent encore la version d'office 2003..... voir encore une version antérieure.... (encore sous XP......)

je vais essayé de me former un peu à cet outil... j'ai commencé à voir quelques vidéos formations d'une personne de MVP cela l'air super puissant... je vais essayé de découvrir ce nouvel outils qui a pourtant déjà presque 10 ans d’existence.... mais dans ma vie pro je ne suis pas sur que cet outil me servira souvent ... mais on a jamais fini d'apprendre....

A+

Fred

resalut Fred

teste aussi (surtout ! ) Power BI Desktop gratuit

ne dépend pas de ton Excel, et contient aussi PQuery

à toi le big data, l'IA et les bases diverses et variées (y compris Excel )

Bonjour jmd,

titre de ce sujet : « Pourquoi penser que son code VBA est le programme en soi ? »

1) il n'y a que de très rares exceptions où le code VBA se suffit à lui-même : il n'a besoin d'aucune des données de la feuille pour faire son travail ; voici quelques exemples simples :

* message informatif à l'ouverture du classeur :

Private Sub Workbook_Open()
  MsgBox "Bienvenue dans cette application X"
End Sub

* message informatif dans une sub classique :

Private Sub AideJeuSolitaire()
  MsgBox "Vous devez sauter par-dessus un pion pour le manger"
End Sub

(ou affichage d'un formulaire pour un texte plus long)

* utilisation d'un formulaire « autonome » :

a) formulaire qui affiche du texte et c'est tout, comme mentionné ci-dessus

b) formulaire avec saisie de donnée et affichage de résultat ; exemples simples de conversion : saisir un montant en francs et le convertir en euros ; saisir une température en °C et la convertir en °F ; une TextBox de saisie de la donnée de base ; affichage du résultat dans un Label ou via MsgBox ; c'est autonome, car y'a aucun besoin de lire les données présentes sur la feuille.


2) dans la très grande majorité des cas, les données sont sur la feuille de calcul, et le code VBA est très étroitement lié à ces données ; il doit notamment utiliser leur position : référence de la cellule ou de la plage de cellules ; s'il y a un objet comme un tableau structuré (ListObject), il doit d'abord y faire référence par son nom ou par son index afin de pouvoir le manipuler.

bien sûr, il faut aussi référencer la bonne feuille de calcul ; mais référencer la feuille de calcul est facultatif si d'après le contexte, on est sûr que ça va agir sur la feuille active.


[quote="dans ton énoncé initial, tu"]

avez-vous remarqué combien de questions sur ce forum son posées sous cette forme :

"j'ai un bug dans mon VBA. Vous trouverez ci-dessous le code"

et on lit le code dans le message, mais aucun fichier n'est joint !

mon impression : les utilisateurs font du code pensant que ce code peut vivre en dehors du fichier Excel où il agit

[/quote]

* il y a les déjà les erreurs de compilation : une mauvaise syntaxe peut être corrigée sans voir la feuille de calcul ; une variable mal orthographiée ou non déclarée peuvent aussi être corrigées sans voir la feuille.

* il y a aussi les erreurs d'exécution : c'est plus difficile à corriger, mais le message d'erreur lui-même peut aider ; donc quand un demandeur dit simplement « ça marche pas », c'est insuffisant : faut plus d'infos ! en particulier le texte exact du message d'erreur, et la ligne de code qui a été mise en évidence en jaune dans le code VBA (mais il n'y a pas forcément de ligne en jaune, et même si elle est présente, l'erreur ne provient pas forcément de cette ligne : la cause de l'erreur peut être plus en amont dans le code)

* il y a aussi des erreurs qui sont ni des erreurs de compilation, ni des erreurs de plantage lors de l'exécution : c'est tout simplement quand la macro ne fournit pas les résultats attendus ; exemple : la macro a soustrait la TVA au lieu de l'additionner ! le programme est bien gentil, mais comme chacun sait, la TVA est un impôt en plus, pas en moins !


quand un demandeur indique son code VBA sans fournir son fichier :

* son code peut être corrigé sans voir la feuille de calcul (plus ou moins facilement), et il le sait (ou il le suppose)

* souvent, il pense à tort qu'on connaît son classeur aussi bien que lui, ou qu'on est à côté de lui, devant son écran et son clavier ; et il ne pense pas à indiquer ce qui est pour lui une évidence, mais pas pour les lecteurs de son post

* ça peut être un simple oubli d'avoir transmis le fichier ou son lien de téléchargement. (clin d'œil pour les demandeurs étourdis qui ont fait cet oubli, et n'ont pas pensé à cliquer sur le bouton Aperçu pour vérifier le contenu de leur post)

* il y a aussi les demandeurs qui ne savent pas comment joindre un fichier

comme on n'a pas le fichier, on est donc souvent obligé d'essayer de deviner les infos manquantes, à la seule lecture du code VBA et / ou des autres infos du post ; mais si l'erreur vient d'une donnée mal saisie ou non conforme, d'un format de cellule inadéquat, d'un espace en trop dans une donnée ou un nom d'onglet, etc... comment faire ? c'est là où il vaut bien mieux avoir le fichier !

dhany

salut dhany

tu as fait une analyse très détaillée des différents problèmes tant en programmation qu'en forumation (néologisme pour "science des forums" )

on pourrait, en inversant chaque phrase (mettre "il faut" quand tu écris "on constate" ) , en faire un mode d'emploi du forum à l'usage des débutants. Il complèterait bien la charte actuelle.

belle analyse !

@jmd

j'ai bien lu ta réponse ; merci pour ton retour !

dhany

Rechercher des sujets similaires à "pourquoi penser que code vba programme soi"