Conseils pour une utilisation facile d'Excel
bonjour
Organisation générale des fichiers
- Un ou des onglets de saisie de tes données, en colonnes toutes simples, tu feras. Pour voir tes données ordonnées et synthétisées, des onglets avec TCD et graphiques tu créeras.
- Un total de 4 classeurs dans ton système jamais ne dépasseras.
- Jamais de fusion de cellules tu ne feras.
- jj/mm/aa les dates tu saisiras, et "01/11/18" au lieu de "Novembre 2018" tu taperas
Fonctions à apprendre
- SI
- RECHERCHEV
Fonctionnalités
- VBA tu n’utiliseras pas, mais les menus de ton Excel tu apprendras.
- Les Tableaux et les TCD de toute urgence tu utiliseras.
- La fonction RECHERCHEV pour lier des Tableaux entre eux tu utiliseras.
- Le menu Données tu étudieras de très très près.
- Pour Excel 2010 et 2013, Power Query tu téléchargeras, et tu ne payeras pas.
- La mise en couleurs avec des MFC et non à la souris tu feras.
- Un classeur par an, avec un onglet par mois jamais ne feras.
- Des tris et des filtres de fou avec un TCD tu feras.
- Des éléments calculés dans les TCD jamais ne feras (le langage est minable). Power BI tu utiliseras.
Présent et avenir
- Les extractions et transferts de données avec le menu Données/Obtenir (ou Power Query pour Excel 2010/2013) tu apprendras.
- Power BI Desktop gratuit pour faire des analyses top du top tu apprendras.
Quand tu sauras tout cela, tu seras un bon utilisateur d’Excel, rapide et apte à répondre à 99 % des besoins
amicalement à tous
Bonjour jmd,
⚠ la règle la plus importante est celle-ci : ne JAMAIS faire de VBA !
la punition serait TERRIBLE ! bien pire qu'après avoir commis la faute du Veau d'Or !
errer pendant 40 ans dans le désert, ce serait de la gnognote, à côté !
dhany
jmd, bonsoir,
Pour tout ce qui est d'une utilisation conforme à un tableur, je suis d'accord avec vous !
Le soucis, c'est que pour beaucoup (et moi le premier) Excel n'est plus un tableur mais une application support pour faire tourner du VBA afin de transformer le tableur en une application "a part entière" comme un bon vieux .exe...
La preuve : Le jeu du pendu...
Voilà, la puissance d'un tableur juste pour servir de support au langage VBA qui peut être assimilé plus facilement grâce à ce support.
J'ai essayé VBE en direct sans le A pour application et j'avoue ne pas avoir tester longtemps car j'ai trouve que tout était plus compliquer car il manquait ce support...
Maintenant, si vous me montrez un jeu du pendu avec PowerQuery et les TCD je pense que je tombe sur mes fesses !
Ou bien alors un site qui explique en prenant "par la main" comment faire une application 100% VBE sans application en support, alors je suis preneur. En effet une application de gestions de stock où tout est "archivé" dans des fichiers ".doc" je trouve cela plus complexe que d'écrire les données dans des cellules de feuilles Excel, mais vous avez raison ce doit être par méconnaissance ou par facilité pour ne pas dire fainéantise !
Donc pour moi Excel va de paire avec VBA (du fait du A) et j'espère m'améliorer afin que ces applications soient encore mieux de jour en jour.
@ bientôt
LouReeD
bonjour à vous
LouReeD,
non, Excel et VBA ne servent plus du tout à créer des jeux ou "applis" (ce fut le cas par le passé).
disons que 99,99% des fichiers Excel font de la gestion de données. Il suffit de lire les questions sur le forum pour le constater.
Et dans ces 99,99% , les 3/4 concernent des bases liées (Excel possède RECHERCHEV pour gérer les liaisons). Mais on a vite des problèmes dès 3 bases.
rem : ce fil ne parle que de gestion de données, comme dit dans son titre. Il est donc étrange que tu y parles de jeux
si on veut faire un jeu ou une appli par lignes de programme, VBA n'est pas la bonne solution car c'est un "mauvais" langage. Il y a en a bien d'autres, plus stables, plus structurés, plus universels, moins sujets aux virus.
il faut être lucide
VBA est un langage qui a eu son heure de gloire
il est aujourd'hui dépassé
mais je peux comprendre que tous ceux qui le maîtrisent le préfèrent.
que conseillerais-tu à tes enfants pour leur avenir d'informaticiens ?
pour moi ce sera Python, R ou C++, en complément d'"Excel avec M et DAX mais sans VBA".
amitiés excelliennes
Bonsoir,
je suis d'accord, si ce n'est sur le 99,99% des sujets
Soit il y en a beaucoup qui parle de classeur de données (d'où le sujet du topic "...gestion de données et surtout parce que ACCESS malgré son nom n'est pas si accessible que ça !
Je me suis mis à parler des jeux, bien que VBA ne soit pas fait pour cela, mais j'aurais pu parler de gestion de location de chambre, ou bien de gestion de compte. Ce que je voulais dire c'est que pour des débutants comme moi, le fait d'avoir une application support sur laquelle on peut "voir" les effets du code VBA, voir même que ce soit celle-ci qui écrit les lignes de codes en fonction de ce que l'on fait, et bien cela semble plus accessible que certain autre langage qui paraissent obscures.
De mémoire le C++ est moins visuel (moins anglophone) que le VBA, non ?
Quand vous dites : (ce fut le cas par le passé).
je répondrais : c'est encore le cas pour ceux qui se mettent sur Excel aujourd'hui... Que ce soit autour de moi ou ici, beaucoup veulent s'y mettre car les changements comme PowerQuery et autre sont trop flou encore à leur yeux.
Et comme les dix commandements, ceux-ci sont valables avec les nouvelles versions, combien d'employeur aujourd'hui tourne encore avec Excel 2003 ? Même pas 2007 et ses 1 000 000 de lignes et 16 000 colonne ! Non 2003 et ses 256 colonnes avec même pas une par jour !
Il y a un nouveau terme que je n'ai pas sous la main, mais c'est l'illettrisme rapporté à l'informatique, et bien hormis les informaticiens et les greffés du portable il y a encore pas mal de monde pour qui MFC ne veut rien dire.
Bref , oui Excel sert à gérer des données, d'ailleurs Microsoft "fait tout" dans ce sens, non ?
Oui il faut apprendre à connaître Excel, ses menus et ses possibilités.
Mais le VBA est là pour certaine que des TCD ne peuvent pas gérer car la demande "sort" du contexte "gestion de données", c'est juste pour le "skin" l'interface et se faire plaisir
Je m'aperçois que je tourne en rond, je n'essaie pas de convaincre d'utiliser VBA, mais d'un autre coté, en étant sur un forum "VBA" (c'est celui qui tourne le plus) je n'essaie pas non plus d'en détourner ceux qui veulent l'utiliser.
@ bientôt (enfin si vous m'avez compris !
LouReeD
Bonjour LouReeD, jmd,
LouReeD a écrit :ACCESS malgré son nom n'est pas si accessible que ça !
)
c'est vrai pour une application avec plusieurs tables qui ont des liens entre elles, et qu'il faut savoir gérer ; mais pour une application avec une seule table, c'est plutôt très facile ! bien sûr, comme pour tout logiciel (dont Excel et Word), il y a quand même un temps d'apprentissage ; on peut se contenter de saisir les données directement dans les tables, des formulaires instantanés et des états instantanés, ainsi que des types de données choisis par défaut, mais bien sûr, ça sera pas optimum ! on peut affiner après-coup, mais celui qui connaît bien pourra créer dès le début ses tables avec les types adéquats bien précis et optimums, réaliser des formulaires et des états plus élaborés que ceux obtenus automatiquement par les boutons « instantané », et quitte à révulser jmd, même pour une application d'une seule table, VBA peut s'avérer très utile !
à propos, jmd, tu m'avais écrit qu'il n'y a qu'un seul langage VBA, car c'est « Visual Basic for Applications » ; désolé, c'est faux : il y a un noyau VBA commun à tous, auquel une partie a été ajoutée pour gérer les spécificités de l'application et en tirer profit ; exemple : en plus du noyau de base, VBE (= VB for Excel) doit gérer les feuilles, les cellules, et tout ce qui fait partie intégrante d'Excel ; tu penses bien que VBW (= VB for Word) n'a pas besoin de gérer des feuilles de calcul vu que Word en contient aucune ! par contre, il doit gérer les paragraphes, les styles, et tout c'qui fait Word ; ni VBE ni VBW n'ont besoin de gérer des diapositives, mais VBP (= Visual Basic for PowerPoint) doit le faire, lui, forcément ! idem pour le VBA adapté spécifiquement pour d'autres applications Office comme Access (gestion des tables, requêtes, formulaires, états, relations) ; idem pour VBA pour Publisher, pour OneNote, et pour Outlook.
note bien que dans un code VBA Excel, la partie qui gère une lettre Word ou un email Outlook ne peut marcher que si on a référencé la bonne API ; sans cela, c'est tout simplement pas possible, puisque c'est pas inclus dans VBE ! mais ce jeu de légo offert par les API rend les choses si subtiles que j'comprends parfaitement qu'tu as pu penser qu'il n'y avait qu'un seul VBA !
c'est volontairement que j'ai pas écrit : « VBW n'a pas besoin de gérer les cellules » ; pourquoi ? pa'c'que Word doit gérer les cellules des tableaux Word, même s'il n'a pas besoin de le faire de façon aussi complète que pour des cellules Excel ; exemple : les cellules des tableaux Word n'ont pas de format numérique ou de protection Verrouillée / Masquée ; et quand on insère dans une page Word un tableau Excel avec liaison, et qu'on double-clique dessus, c'est géré par VBE et non par VBW ; CQFD.
dhany
re
LouReeD,
- pour faire un jeu, oui il faut VBA mais parce qu''on a mal choisi son programme en prenant Excel.
- avec Excel, pour faire de la gestion de chambres d'hôtel ou une compta perso ou pro simple, il n'y a aucun besoin de VBA
note importante : 3/4 des questions sur le forum sont professionnelles (ou personnelles "sérieuses" comme une compta perso) et ne concernent donc pas un "plaisir personnel de hobbyiste". Il faut de la rigueur, de la stabilité, de la durabilité et de la maintenabilité par un collègue. VBA répond mal à ces exigences.
dhany,
certes il y a des fonctions différentes selon la version de VBA pour Word ou pour Excel ou PPoint
mais il s'agit bien d'un unique langage, avec les mêmes règles (ou absences regrettables de règles
l'insertion d'un objet W dans E ou inversement ne change rien à ce fait.
amitiés à tous
[...]à propos, jmd, tu m'avais écrit qu'il n'y a qu'un seul langage VBA, car c'est « Visual Basic for Applications » ; désolé, c'est faux : il y a un noyau VBA commun à tous, auquel une partie a été ajoutée pour gérer les spécificités de l'application ...
Il n'y a qu'un seul VBA, (pour Application). Il n'y a pas de VBA pour Excel, VBA pour Word, VBA pour FSO, ...
Ce n'est pas une partie spécifique pour chaque application qui est ajoutée mais simplement le fait que la référence à l'application support est implicite (il n'y a pas besoin de la déclarer). Que ce soit dans Excel, Word ou autre la syntaxe du VBA est rigoureusement la même pour peu qu'on ait établi la référence à chaque application utilisée. En outre, le VBE est l'IHM du VBA : le Visual Basic Editor.
Je suis entièrement d'accord avec jmd quand aux problèmes de portabilité et maintenabilité qu'engendre l'utilisation du VBA, il est préférable de s'en passer chaque fois que c'est possible.
Bonsoir Patrice33740,
je ne suis pas du tout d'accord avec toi : j'ai bien longuement expliqué qu'il y a effectivement un noyau VBA qui est le même pour tous les VBA (Visual Basic for Application) ; ce noyau est en grande partie inspiré ou repris de celui du VB (Visual Basic) indépendant ; ensuite, chaque VBA est complété par les spécificités de l'application support (Excel, Word, PowerPoint, ou autre...) pour donner un Visual Basic adapté spécifiquement à l'application, comme VBE (Visual Basic for Excel) ; c'est dans ce sens où je persiste à dire qu'il n'y a pas qu'un seul VBA mais plusieurs ; après, « chacun voit midi à sa porte » !
et de toutes façons, que mon VBE favori soit considéré comme un langage VBA identique aux autres ou non, ça ne change rien à l'appréciation que j'en ai, et j'aime toujours autant l'utiliser !
source Wikipédia :
dhany
Bonsoir dhany,
Ce n'est ni Wikipédia, ni quelques bouquins de vulgarisation, mais Microsoft qui défini le VBA :
http://interoperability.blob.core.windows.net/files/MS-VBAL/[MS-VBAL].pdf
Et tu remarquera qu'il n'y a ni Workbook, ni Worksheet, ni aucun Objet qui appartienne à l'Application support !
@Patrice33740
tu a écrit :Ce n'est ni Wikipédia, ni quelques bouquins de vulgarisation, mais Microsoft qui défini le VBA
je suis entièrement d'accord là-dessus !
tu a écrit :il n'y a ni Workbook, ni Worksheet, ni aucun Objet qui appartienne à l'Application support !
ben oui, c'est normal : ta doc est pour le noyau VBA dont j'parlais, et c'est ce noyau qui est identique pour toutes les applications Office.
extrait de ta doc :
1.3 Vue d'ensemble des spécifications du langage VBA
VBA est un langage de programmation pour ordinateur qui est censé être utilisé en conjonction avec une application logicielle hôte telle qu'un traitement de textes. Dans une telle situation, l'utilisateur final d'une telle application hôte utilise le langage VBA pour écrire des programmes qui peuvent accéder aux données et aux fonctionnalités de l'application, et aussi les contrôler.
alors par rapport à Excel : tu as écrit que ce VBA ne contient aucun objet de l'application hôte (ni Workbook, ni Worksheet ou autre) ; exact, vu que c'est le noyau ; mais alors, c'est bien car une autre partie y a été ajoutée pour former le VBE (Visual Basic for Excel) qu'on peut écrire des codes VBA qui peuvent manipuler des objets Excel : un classeur Excel (Workbook), une feuille de calcul (Worksheet), des cellules (Range), etc... CQFD !
Word ne contient pas de classeur Excel, ni aucune feuille de calcul, ni beaucoup d'autres choses propres à Excel : son VBA n'a donc pas besoin de les gérer ; par contre, il doit gérer les paragraphes, styles, et autres particularités de Word ; comme le noyau du VBA de Word est identique aux autres, il faut bien, forcément, que là aussi, une autre partie lui ait été ajoutée pour pouvoir écrire des codes VBA gérant les objets de Word !
c'est donc ces différentes parties ajoutées qui font que VBA n'est pas un seul et unique langage ! le noyau seulement : oui ; mais c'est tout !
donc ta doc Microsoft elle-même me permet de confirmer ce que j'ai écrit ! re-CQFD !
maint'nant, si jmd ou toi vous tenez absolument à penser qu'y'a un seul et unique VBA, ça m'dérange pas du tout !
comme déjà écrit dans un post précédent, que VBA soit un langage unique ou non, ça change rien à mon utilisation perso d'VBA.
dhany
Bonjour,
@[dhany
Comme tu l'as très justement écrit :
[quote=dhany post_id=710490 time=1543280074 user_id=51200]
1.3 Vue d'ensemble des spécifications du langage VBA
VBA est un langage de programmation pour ordinateur qui est censé être utilisé en conjonction avec une application logicielle hôte telle qu'un traitement de textes. Dans une telle situation, l'utilisateur final d'une telle application hôte utilise le langage VBA pour écrire des programmes qui peuvent accéder aux données et aux fonctionnalités de l'application, et aussi les contrôler.[/quote]
Rien n'est ajouté, C'est tout simplement que VBA utilise les fonctionnalités qui existent déjà dans l'Application référencée.
PS : C'est là l’intérêt du VBA, une simple référence permet d'utiliser les fonctionnalités d'une application qu'elle soit MS ou autre.
Bonjour Patrice33740,
j'ai écrit : « car une autre partie y a été ajoutée pour former le VBE (Visual Basic for Excel) »
par « ajoutée » je voulais parler d'une extension VBA par rapport au noyau de base.
dhany
par « ajoutée » je voulais parler d'une extension VBA par rapport au noyau de base.
Mais il n'y a aucune extension, tout ce que tu décris, sont des fonctionnalités qui existent dans Excel, Word, ... pour leur propre fonctionnement, indépendamment du VBA.
VBA ne fait que "s'y connecter".
tu a écrit :des fonctionnalités qui existent dans Excel, Word, ... pour leur propre fonctionnement, indépendamment du VBA.
oui, et heureusement ! j'suis d'accord avec ça ! c'est bien des fonctionnalités de l'application, qui existent déjà ; mais pour ce qui est de pouvoir les manipuler par VBA, le noyau de base ne le peut pas, lui, car ce noyau commun de tous les VBA ne connaît pas les spécificités d'une application ; et c'est justement pour ça que Microsoft a dû développer une extension du langage VBA propre à chaque application ; et c'est cette extension qui peut gérer les fonctionnalités propres de l'application ; c'est aussi cette extension spéciale pour chaque application qui fait qu'il n'y a pas qu'un seul VBA ; exemple : le VBE d'Excel : « Visual Basic for Excel ».
dhany
bonjour à vous
au-delà de la discussion VBA ou VBpourexcel, il faut reconnaître qu'on peut s'en passer et qu'on DOIT s'en passer
je cherche plutôt à compléter mes conseils du message #1 de ce fil. Lâchez-vous
amitiés à tous
connaissez-vous Microsoft Flow ?
[...] VBA ou VBpourexcel, il faut reconnaître qu'on peut s'en passer et qu'on DOIT s'en passer
je cherche plutôt à compléter mes conseils du message #1 de ce fil. [...]
Bonjour jmd
Entièrement d'accord, tu peux y ajouter les 13 règles d'or de Gaëtan Mourmant :
Tiens ce fil m'avait échappé ! Bonjour tous !
Quand on joue sur les mots, les discussions peuvent s'allonger indéfiniment !
Le langage de programmation en tant que tel est unique, mais est bien décliné en versions par application...
En ouvrant le menu Outils > Références de l'éditeur dans Excel on peut vérifier que la référence à la bibliothèque d'objets Excel y est automatiquement établie. Ce qui ne sera pas le cas si on ouvre Word ou Powerpoint...
C'est ce qui permet en travaillant avec VBA pour Excel d'avoir accès directement aux composants d'Excel.
Par ailleurs, je persiste toujours à ne pas comprendre les oppositions que l'on fait entre VBA et des fonctionnalités d'Excel. L'intérêt ou non d'utiliser VBA pour telle ou telle chose peut s'apprécier selon des critères très divers, mais dès lors que l'on peut trouver un intérêt, même minime, à utiliser VBA, si l'on s'en sert pour actionner les fonctionnalités Excel, elles ne seront pas actionnées différemment que si l'on opérait manuellement. Je ne vois vraiment pas pourquoi un TCD ne devrait pas être actualisé par une procédure VBA.
Cordialement.