macro tri Excel

Version imprimable

1 pièce(s) jointe(s)

macro tri Excel

Bonjour à tous,
j'ai fait un classeur Excel pour gérer des courses des chauffeurs d'une assos. Parmi les macros que j'utilise, les macros TRI (lancées par un bouton) fonctionnent bien sur le pc ou je les ai faites, par contre, lorsque je copie mon classeur sur une autre machine,
la macro perd un peu ces petits !... le lancement génère une erreur et me propose le débogueur… Le classeur à bien été copié dans le même répertoire etc …
il y a 12 journées J1, J2 etc... avec chacune sa macro pour le tri. Le problème est le même bien sûr pour chacune d'entre elles
outre le tri par heure, la macro sauvegarde le classeur
voici le code de la macro:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Sub M_tri_j1_saveDD() ' ' M_tri_j1_saveDD Macro ' ' Range("A4").Select ActiveWorkbook.Worksheets("J1").ListObjects("Tableau21").Sort.SortFields.Clear ActiveWorkbook.Worksheets("J1").ListObjects("Tableau21").Sort.SortFields.Add2 _ Key:=Range("A4"), SortOn:=xlSortOnValues, Order:=xlAscending, DataOption _ :=xlSortNormal With ActiveWorkbook.Worksheets("J1").ListObjects("Tableau21").Sort .Header = xlYes .MatchCase = False .Orientation = xlTopToBottom .SortMethod = xlPinYin .Apply End With ' cette partie sauvegarde le classeur, en remplacement du classeur existant … sans alerte... Application.DisplayAlerts = False ChDir "C:\transport_Pas" ActiveWorkbook.SaveAs Filename:="C:\transport_Pas\chauffeurs.xlsm", _ FileFormat:=xlOpenXMLWorkbookMacroEnabled, CreateBackup:=False endsub
pour que cela fonctionne je suis obligé de refaire toutes ces macros sur le nouveau PC

merci par avance pour vos recherches.
Cordialement
Rolby :P

21/02/2020, 17h19
vinc_bilb
Bonjour,

Sans ouvrir votre fichier .... Et ça donne quoi en mode pas à pas avec le debuggeur? Où est l'erreur?
Par exemple:
Code:

1 2 ActiveWorkbook.SaveAs Filename:="C:\transport_Pas\chauffeurs.xlsm", _ FileFormat:=xlOpenXMLWorkbookMacroEnabled, CreateBackup:=False
=> le répertoire existe-t-il par défaut?
22/02/2020, 09h11
rolby65

1 pièce(s) jointe(s)
bonjour vinc_bilb,

le répertoire existe bien dans c:
le debbogage s'arrête à:
Code:

1 2 3 ActiveWorkbook.Worksheets("J1").ListObjects("Tableau21").Sort.SortFields.Add2 _ Key:=Range("A4"), SortOn:=xlSortOnValues, Order:=xlAscending, DataOption _ :=xlSortNormal
est-ce que l'erreur se trouve forcement à l'endroit ou s'arrête le debbogueur ?
je vous joints le classeur entier pour que vous puissiez voir, si vous avez le temps, l'environnement complet ou devrait s'exécuter cette macro.
(j'ai donc créé précédemment dans c: "C:\transport_Pas\" et mis le classeur dedans)

je précise que lorsque je construis cette macro avec l'enregistrement macro du menu developpeur elle fonctionne parfaitement.
c'est seulement quand je copie mon classeur sur un autre ordi ' respectant le répertoire etc... que l'erreur se produit .

merci pour l'intérêt que vous portez à mon problème

Cordialement
Rolby :)
24/02/2020, 08h59
révèr

Bonjour vinc et rolby,

Tu peux utiliser Debug.Print pour repérer où se situe l'erreur.

Aide Microsroft sur Debug.Print -> https://docs.microsoft.com/fr-fr/off...p/print-method

As-tu vérifié dans la copie de ton classeur que Tableau21 existe toujours sous ce nom ?

Bonjour ...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ' Range("A4").Select ActiveWorkbook.Worksheets("J1").ListObjects("Tableau21").Sort.SortFields.Clear ActiveWorkbook.Worksheets("J1").ListObjects("Tableau21").Sort.SortFields.Add2 _ Key:=Range("A4"), SortOn:=xlSortOnValues, Order:=xlAscending, DataOption _ :=xlSortNormal With ActiveWorkbook.Worksheets("J1").ListObjects("Tableau21").Sort .Header = xlYes .MatchCase = False .Orientation = xlTopToBottom .SortMethod = xlPinYin .Apply End With ...
Proposition : remplacer toutes ces lignes par (1 seule)

Code:

[Tableau21].Sort [Tableau21].Columns, 1, Header:=1

Remarque : pour trier selon une autre colonne x :

Code:

[Tableau21].Sort [Tableau21].Columns(x), 2,Header:=1

(,1, pour un ordre croissant et ,2, pour un ordre décroissant)

Nota : avec [Tableau21], l’évaluation sous-jacente de cette saisie tient compte, parmi tout ce qui est prévu, de l’emplacement du tableau dans le classeur donc permet de déplacer le tableau n’importe où dans ce dernier sans toucher aux macros .
Bien sûr on peut utiliser Sheets(1).ListObjects("Tableau21") mais l’évaluation sous-jacente exige que le tableau soit placé dans la feuille indiquée sous peine de …
On peut utiliser aussi, Range("Tableau21"), mais avec prudence. Cette notation, utilisée dans le module de feuille d’un onglet qui ne contient pas Tableau21, pose problème. Dans ce cas, le référencement s’impose avec Feuilx.Range ("Tableau21").

Salut

Citation:

Envoyé par OrDonc

[...]
On peut utiliser aussi, Range("Tableau21"), mais avec prudence. Cette notation, utilisée dans le module de feuille d’un onglet qui ne contient pas Tableau21, pose problème. Dans ce cas, le référencement s’impose avec Feuilx.Range ("Tableau21").

Outre la notation à crochets qui n'est pas une bonne pratique ^*(notamment parce qu'elle ne permet pas la saisie semi-automatique, mais pas que) et que je déconseille donc fortement, le problème soulevé ici résulte d'un défaut d'architecture. Le code d'une feuille ne devrait jamais avoir à manipuler un tableau structuré se trouvant sur une autre feuille. il devrait être déporté dans un module standard et à cet endroit, il n'y aura aucun problème à utiliser Range("Tableau1"). En utilisant la notation [tableau1], tu passes par le modèle objet d'Excel, mais tu enfreins la règle d'encapsulation propre à la POO (programmation orientée objet) et tu crées un problème d'architecture dans ton code (dont découleront d'autres problèmes par la suite). Il me semble toujours important de porter une attention de chaque instant sur la bonne architecture de code. Si vraiment, pour une raison que j'ai des difficultés à cerner, le code d'un module de classe (ce qu'est le module d'une feuille) devait manipuler un tableau structuré, il s'agirait alors, toujours pour respecter la règle d'encapsulation, d'introduire le tableau dans l'objet (via une méthode ou une propriété), car un module de classe ne peut pas manipuler une variable qui ne lui a pas été explicitement passée. C'est pourquoi il n'est pas prudent de "contourner l'obstacle" en faisant appel au concept d'évaluation du modèle Excel (ce que fait la notation à crochets qui n'est pas du VBA natif mais qui fait appel à la bibliothèque Excel) et qu'il est préférable de revoir son architecture.

Le problème de cette notation à crochets est qu'elle amène à se passer également de l'utilisation intuitive des constantes d'Excel, notamment xlAscending, xlGuess, et oblige le codeur à mémoriser les valeurs numériques correspondantes. De plus, je suis loin d'être fan des raccourcis utilisés ici pour "faire tout en une ligne", car c'est méconnaitre le fait qu'Excel mémorise les options de la boite de dialogue du tri, pouvant amener à certaines déconvenues lorsque c'est mal utilisé. Il est de loin préférable, comme le demandeur l'a fait, de préciser toutes les options de tri pour être certain que le résultat est conforme aux attentes.

@Rolby65: Normalement, le code qui enregistre le classeur ne devrait pas se trouver dans la même procédure que le code qui trie. Une règle à adopter est de créer des procédures/fonctions qui n'ont qu'une seule responsabilité. Ainsi, tu peux tester la procédure de tri et celle de sauvegarde indépendamment l'une de l'autre. Ca te permet de circonscrire l'erreur et de limiter ton périmètre de recherche de l'erreur. Essaie également de ne pas mettre de données "en dur" dans ton code, tel que le chemin d'accès ou le nom du fichier. De cette manière, tu pourras plus facilement migrer ton classeur dans un autre environnement sans devoir recréer ou modifier ton code ou ton arborescence. Un bon endroit pour ce genre de données est une feuille de paramètres dans laquelle tu stockes ces infos, éventuellement sous forme de "plage nommée".

Il serait préférable de nommer correctement tes tableaux. Je suppose que tu vas souhaiter pouvoir trier chaque tableau journalier. Du coup, il serait préférable que la macro de tri soit indépendante d'un tableau particulier, et reçoive ce qu'elle doit traiter en argument. Cela te permettra d'avoir une seule procédure de tri pour tous tes tableaux journaliers. Il suffira de passer le bon tableau en fonction par exemple de la feuille active.

J'ai réaménagé un peu ton code pour que tu vois qu'avec un tableau structuré, tu n'as à te préoccuper ni de la feuille dans laquelle se trouve ton tableau, ni de la place de celui-ci dans la feuille (pas de Worksheets("J1").ListObjects("Tableau21"), et pas de Key:=Range("A4") qui verrouillent l'emplacement du tableau). De cette façon, la macro Sort est générique à tous tes tableaux journaliers. Note également que tu peux atteindre un listobject par sa plage nommée, sans devoir passer par la feuille qui le supporte.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Sub Sort(Table As ListObject) With Table.Sort .SortFields.Clear .SortFields.Add Key:=Range(Table.Name & "[heure]"), _ SortOn:=xlSortOnValues, _ Order:=xlAscending, _ DataOption:=xlSortNormal .Header = xlYes .MatchCase = False .Apply End With End Sub Sub SaveWorkbook() ActiveWorkbook.SaveAs Filename:=Range("NomFichier"), FileFormat:=xlOpenXMLWorkbookMacroEnabled End Sub
^* J'attends toujours que les utilisateurs de cette notation m'en indique les avantages, mais je pense que je peux malheureusement attendre longtemps, vu qu'il n'y a aucun avantage à l'utiliser, alors que les désavantages liés à son utilisation sont nombreux.