Youpi !
J'ai enfin trouvé un bout de code qui fonctionne pour mon test et insertion de ligne.

Il me reste maintenant à faire fonctionner ensemble le formattage et les insertions de ligne qui fonctionnent pour l'instant mais l'un après l'autre.

A suivre ;)

Bonjour Megaolive, le Forum,

Je ne t'oublie pas, je regarde ce soir ce que je peux te proposer...

Cordialement,

Re Megaolive,

Comme promis, me revoici

J'ai brièvement analysé ton code et ta façon de procéder. Je vais te faire quelques remarques que je souhaite [I]constructives[/I], et qu'il convient de prendre NON PAS [I]à la lettre[/I] (je n'ai évidemment pas le monopole du savoir et de la vérité), mais tout simplement comme conseils ou suggestions. A toi d'en retenir ce que tu penses être intéressant...

[LIST][*]Tout d'abord, un bon point : l'utilisation d'[I]Option Explicit [/I](pour forcer la déclaration des variables) est une excellente chose.
[*]Par contre, la déclaration systématique de tes variables en tête de module n'est pas conseillée. Il convient de le faire plutôt en tête de chaque procédure (Sub / End sub). Pourquoi ?
Les déclarations en tête de module sont réservées aux variables dont la valeur doit être conservée et être réutilisée par plusieurs procédures (en ajoutant le mot clé [I]Public [/I]comme tu l'as fait, tu permets même de les réutiliser dans d'autres modules). On s'aperçoit que ce n'était pas ton intention de faire, car par exemple, tu déclares une fois [I]FormatSheet[/I] en tête de module, mais tu lui réaffectes sa valeur dans chaque procédure [I]Sub copy???format()[/I] par la ligne [I]Set FormatSheet = Worksheets("FORMAT")[/I]. D'une manière générale, puisque leur valeur est conservée par Excel, les variables déclarées en tête de module sont plus consommatrices de ressources que celles internes aux procédures, c'est pourquoi il convient de les utiliser avec parcimonie... Les variables déclarées à l'intérieur des procédures libèrent la mémoire qui leur est allouée dès que l'instruction [I]End Sub[/I] est rencontrée.
[*]Ensuite, j'ai vu que tu utilisais souvent la sélection des cellules (par l'instruction [I]Select[/I]) avant leur traitement. Sache qu'en VBA, c'est le plus souvent inutile. C'est même source d'erreur parfois, pas franchement agréable pour l'oeil de l'utilisateur et c'est aussi un facteur de lenteur pour application car ça ralentie considérablement les traitements. Certaines instructions vont créer d'office des sélections, c'est le cas par exemple de la méthode [I]Paste[/I], mais ça tu n'y peux rien. Par contre, si tu peux l'éviter, alors il faut le faire.
[*]Et pour finir, un autre bon point : la présentation de ton code est assez claire et bien structurée. Et les commentaires sont bien pratiques [/LIST]

Voilà c'est, j'espère, l'analyse que tu attendais...

Pour finir, voici le code issu de ma propre conception des choses. J'ai notamment pris le parti de parcourrir le tableau "à l'envers". Cette façon de faire me semble plus adaptée et en particulier pour permettre l'insertion de lignes dans le tableau sans être gêné dans les boucles... Si tu dois un jour procéder à des suppressions de lignes en boucle, je te conseille de retenir également ce même principe.

Voici le code que j'ai utilisé dans ton exemple ci-joint modifié :




Cordialement,

J'en ai révé Mdf l'a fais :p
On peut tester en remontant :p

Tout d'abord merci pour les critiques !!!
je pensais avoir fais preuve d'une bonne initiative pour les variables publique en début de code :p
mais je comprend tout a fais ta correction !!!!

Mon problème quand à la "selectomania" c'est que j'ai approché Excel par l'interface utilisateur avant tout...
Heureusement tes commentaires m'ouvrent beaucoup de nouvelles portes...Et dans ta solution je vois déja des mines d'astuces !!!
Merci pour ton aide éclairée !

Je viens de lire et relire le code que tu as édité...
J'ai un soucis de compréhension (avant de me relancer sur l'éditeur)

Dans la dernière sub

C est sur Lfin que je butte :p
A la lecture, j'ai l'impression qu'il va copier les lignes de conso en bas de tableau les une a la suite des autres :p

Re,

Avant d'éditer ton post (d'ailleurs, si tu pouvais éviter de trop le faire ça serait bien lol, car ce n'est pas toujours évident à suivre...), tu demandais un remède à la "selectomania"... en voici un :




Citation :
Humm, pas facile d'expliquer la démarche adoptée...

La variable Lfin marque la fin d'un bloc Conso.
Comme je vais en remontant, au départ Lfin est équivalent à la fin du tableau.
Dans la boucle, toujours en remontant, lorsque je rencontre un élément Conso (en gras), je coupe la ligne correspondante et la copie sur la ligne repérée Lfin . Immédiatement après, je redéfinie Lfin qui marquera ainsi la fin du bloc suivant, et ainsi de suite...
Le couper-coller est assuré par une procédure indépendante (DEPLACEconso) par souci de clarté. Je lui passe en argument la ligne en cours (celle que je vais couper) et la ligne "cible" (celle qui va recevoir le coller). Cette ligne "cible" est justement définie par Lfin.

J'espère que ces explications pourront t'aider à comprendre ce code...

Cordialement,

Cher Guru, :]




ça y est, j'ai relu de bon matin :p
LFin = L après avoir déplacer la conso permet de décaler la prochaine cible ....

Je vais travailler un peu mon code voir à quoi j'arrive.
Merci encore !

Bonjour Megaolive, le Forum,

Merci de préfixer ce fil en [résolu] lorsque tu estimeras que c'est le cas.

Cordialement,

Je le flague tout de suite

par contre de mon coté,
je dois continuer de travailler un peu mon code avant de le soumettre :p

Olivier