Mise a jour

Le 04/03/2017 à 21:02

Bonjour,

Je voudrais arrange une mise a jour sur le fichier plan

si on clic sur ce bouton, le tableau est mis à jour :

  • determiner le nom de l'application dans la colonne A
  • dans la feuille config, recopier les valeurs pour toutes les colonnes en jaune pour cette application.
  • le nom des colonnes doivent pouvoir être parametrables dans la feuille config (l'ordre et le nom peuvent changer).
C'est a dire L'ordre des applications et l'ordre des colonnes peuvent changer dans la feuille plan mais la mise a jour et le module dois cas meme faire la mise a jour.

Merci

24test.xlsm (25.16 Ko)
Le 05/03/2017 à 01:02

Salut Keurnet,

clair comme de l'eau de roche!

T'imagines-tu le nombre de situations que l'on peut rencontrer tous les jours dans tous les domaines possibles et imaginables?

Tu parles de plusieurs applications, plusieurs configurations, des noms qui changent, des colonnes qui voyagent... et nous n'avons, pour comprendre ton monde, que deux tableaux vides et une macro qui fait des bêtises!

Alors, tu nous fais un fichier exemple, avec plusieurs situations de départ et leur heureux dénouement comme tu le désires!

Après, on discute!

A+

Le 05/03/2017 à 01:20

tout ce que je voudrais c'est que si j'appui sur mon bouton qu'ils copie ce qu'il y'a sur la feuil "config" dans mon fichier "plan"

de sorte que meme si je deplace une application qu'il reussice a faire la mise a jour et copier ces donnees.. ce fichier est mon exemple

Le 05/03/2017 à 08:12

bonjour à tous

c'est pas trop clair comme le dit curulis

étant donné que tu as 2 feuilles qui se ressemblent, pourquoi recopier des données (par VBA comme si on travaillait sur du papier) ? on peut utiliser des formules.

si on déplace un classeur, ça fonctionnera encore. Et même si les feuilles sont dans des classeurs différents qu'on déplace, il suffit d'un clic de rétablir les liaisons.

Le 05/03/2017 à 13:46

je m'exerce sur VBA pour les formules je les metrise assai bienje veux faire mes debut sur vba

Le 05/03/2017 à 14:43

Bonjour,

Si tu fais ça à titre d'entrainement... 

Sub MajPlan()
    Dim TPl(), APl, i%, n%
    ReDim TPl(1 To 31)
    APl = Worksheets("PLAN").Range("A1:AE1").Value
    With Worksheets("Config")
        For i = 1 To 31
            n = WorksheetFunction.Match(APl(1, i), .Range("A1:AE1"), 0)
            TPl(i) = .Cells(2, n).Resize(26).Value
        Next i
    End With
    Application.ScreenUpdating = False
    With Worksheets("PLAN").Range("A2:AE27")
        .ClearContents
        For i = 1 To 31
            .Columns(i).Value = TPl(i)
        Next i
    End With
End Sub

Là, on prend dans config pour mettre dans Plan, comme indiqué dans ton 2e post, bien que le premier semblait dire le contraire, mais il n'y a le cas échéant qu'à inverser... L'essentiel pour toi est de voir ce que fait le code... et de noter les problèmes éventuels laissés de côté (sur lesquels tu pourras utilement te pencher).

Quelques conseils pour des débuts efficaces en VBA :

  • oublier l'enregistreur,
  • bannir tout commande Select ou Activate en cours d'opération,
  • qualifier tes expressions avec des références explicites à l'objet conteneur (sans laisser VBA chercher l'élément actif implicite),
  • utiliser des commandes VBA de préférence à des commandes Excel équivalentes (ne recourir à des commandes Excel que si pas d'équivalent en VBA ou si plus simple),
  • travailler au maximum hors Excel en VBA (schéma souhaitable : on prélève les données utiles, on les travaille hors Excel, on restitue le résultat à la fin),
  • garder présent à l'esprit que si l'on utilise VBA c'est pour faire autrement qu'on le ferait avec Excel, ce que VBA permet !
  • et aussi indenter son code, autant que possible selon des règles rigoureuses, cela fera gagner beaucoup de temps...

Cordialement.

Le 05/03/2017 à 14:56

Merci Beaucoup Je vais m'inspirer de ce code pour le comprendre Ca ma beaucoup aider Merci Beaucoup

Le 05/03/2017 à 14:57

bonjour à tous

salut MFerrand,

dans les conseils, j'ose ajouter :

commenter son code

(plus on débute, plus il faut commenter en détail)

Le 05/03/2017 à 15:41

Salut jmd,

Je reconnais que des commentaires sont utiles au débutant... mais je conseillerais personnellement (je ne l'ai pas mentionné car c'est plutôt très perso ! ) de les réduire au minimum qui lui est indispensable (et éliminer les commentaires qu'il connaît déjà et qui ne lui apporteront plus rien).

J'ai fait quelquefois des commentaires véritablement explicatifs (et qui ne pouvaient tout de même pas être qualifiés d'exhaustifs, on aurait encore pu en rajouter), le résultat est que pour presque chaque ligne de code, il y avait entre 4 et 8 lignes de commentaires !

Dans ces conditions, je suis pour avoir une copie commentée, destinée à l'étude, et une version non commentée pour travailler, car on ne peut plus travailler correctement sur un code noyé dans des commentaires.

Pour ma part, lorsqu'il m'arrive d'en mettre, c'est plus en tant que balises, pour découper des parties distinctes d'une procédure un peu longue, où dans ce cas ça m'évite de chercher où commence telle ou telle partie...

Mais je sui bien d'accord que pour un débutant les commentaires peuvent être indispensables...

Je n'avais d'ailleurs pas le même point de vue à mes débuts ! Je reste toujours partant pour fournir des explications détaillées sur un bout de code... mais il me semble préférable que l'intéressé en traduise lui même en commentaires ce qui lui sera utile...

Cordialement.

Le 05/03/2017 à 17:14

re MFerrand

j'ai bien vu les nombreuses lignes de commentaires (hors du code) que tu as données dans ton message Dim Mars 05, 2017 2:43 pm

bonne fin de journée

amités excelliennes

Le 05/03/2017 à 19:45

Le 10/03/2017 à 22:10

Bonjour le fil

J'approuve

jmd a écrit :

dans les conseils, j'ose ajouter : commenter son code (plus on débute, plus il faut commenter en détail)

MFerrand a écrit :

Quelques conseils pour des débuts efficaces en VBA :

  • oublier l'enregistreur,
  • bannir tout commande Select ou Activate en cours d'opération,
  • qualifier tes expressions avec des références explicites à l'objet conteneur (sans laisser VBA chercher l'élément actif implicite),
  • utiliser des commandes VBA de préférence à des commandes Excel équivalentes (ne recourir à des commandes Excel que si pas d'équivalent en VBA ou si plus simple),
  • travailler au maximum hors Excel en VBA (schéma souhaitable : on prélève les données utiles, on les travaille hors Excel, on restitue le résultat à la fin),
  • garder présent à l'esprit que si l'on utilise VBA c'est pour faire autrement qu'on le ferait avec Excel, ce que VBA permet !
  • et aussi indenter son code, autant que possible selon des règles rigoureuses, cela fera gagner beaucoup de temps...

par contre j'ajouterais (pardon MFerrand)

  • l'enregistreur de macro-cmdes il ne faut l'utiliser... mais il faut grandement s'en inspirer !
  • et surtout supprimer tout le code superflu qui génère !

et encore....

- il faut absolument indenter le code

puis encore... quelques règles pour faciliter la lecture du code

- utiliser des noms de variables courts et explicites et mettre aux oubliettes les I,J,K de nos débuts

=> une variable explicite c'est une variable qui dit d'un seul coup d'œil ce qu'elle fait, à quoi elle sert... par exemple :

cpt pour un compteur

colAct pour colonne actuelle (ou COLonne ACTuelle pour rappeler mes commentaires - clin d'œil à MFerrand)

- en ce qui me concerne une variable commence toujours par une minuscule (pas de underscore) mais des majuscules à chaque changement de noms/mots (clefRefClient, clefTrouve...)

Et un autre point des plus important pour la lecture (dirais-je linéaire du code)

  • ne jamais utiliser EXIT (sauf éventuellement pour la gestion des erreurs)
  • il y a toujours un moyen de tourner le test/code dans l'autre sens

et j'ajouterais en plus et surtout...

- lorsque l'on se lance dans VBA il ne faut pas penser "comment Excel ferait ça" mais "comment j'aimerais le faire"

je veux dire par là qu'il ne s'agit pas de se lancer tête baissé dans du code au kilomètre sans aucune efficacité mais plutôt de réfléchir à ce que l'application doit fournir comme résultat et en fonction de cela combien et comment je dois présenter mes données...

en résumé VBA s'apprend par l'exemple (par le forum aussi), la programmation se découvre par la réflexion

Comme dirais certains il faut penser BDD/SGBD et non papier/crayon !

Rechercher des sujets similaires à "mise jour"