Non, ce n'est pas grave.

Tu peux aussi modifier le curseur au dessus d'un formulaire ou d'un contrôle.
En plus tu peux afficher un curseur de ton cru.

Chouette, non?

Cordialement,

Guy

Repère le fichier ClasseurAuto.bat dans le dossier où tu l'as mis.

Clic Droit avec la souris, deuxième ligne (sur mon poste du moins) menu Modifier.
Le fichier ClasseurAuto.bat s'ouver en mode texte.

Remplace "C:\Documents and Settings\Guy\Mes documents\Office\Excel\myDearFriend\ClasseurChonoAuto.xls"
Par le chemin du fichier ClasseurChonoAuto.xls sur ton poste.

Pour ne pas te casser la tête :

1. Ouvre le fichier ClasseurChronoAuto.xls dans Excel.
2. Ouvre l'éditeur VBA.
3. Ouvre la fenêtre Exécution Ctrl+G
4. Tape dans la fenêtre Exécution : ? ActiveWorkbook.FullName puis Entrée.
5. La ligne suivante affichera le chemin complet du classeur, copie-la et colle-la dans ClasseurAuto.bat sans oublier les guillemets.

Cordialement,

Guy

Pas de panique, je m'attendais à ça.

Procédure à suivre

1. Lancer le fichier ClasseurAuto.bat
2. Excel ouvre le classeur ClasseurChonoAuto.xls
3. Un message "On effectue le traitement et on ferme" s'affiche.
4. C'est à ce point qu'il faut taper Ctrl+Pause.
5. Excel affiche alors le formulaire de débogage avec le message "Exécution interompue"
6. Cliquer sur Fin et voir le code.

Tout simple.
J'aurais quand même dû être plus clair dans ma phrase :«Quand tu voudras voir le code attend le message à l'écran puis fait Ctrl+Pause pour arrêter l'exécution.». Je te l'accorde.


Guy

Bonjour manuBX,

Un petit exemple qui marche à condition que tu sois sous Windows. Pour Mac, brumes et mystères.

Ce fichier s'ouvre, affiche un message et se referme.
Dans la procédure Workbook_Open() l'appel à la procédure QuelqueChose() représente l'action que tu voudras effectuée lors de l'ouverture du fichier. Une fois le traitement terminé, le classeur se ferme.

Jette un oeil dans la procédure Workbook_Open()

Voilà pour le classeur qui se ferme tout seul.

Comment faire pour qu'il s'ouvre à une heure précise?

Voir le petit fichier ClasseurAuto.bat joint.  C'est un appel à Excel.exe avec en paramètre le chemin complet du classeur à ouvrir. Dans l'exemple donné le fichier .bat contient start Excel "C:\Documents and Settings\Guy\Mes documents\Office\Excel\myDearFriend\ClasseurChonoAuto.xls" /e
Tu modifieras le chemin du classeur selon l'endroit où se trouve le classeur ClasseurChonoAuto.xls sur ton poste.

Une fois la correction de chemin effectuée, ajoute une tâche planifiée dans Windows qui démarrera ClasseurAuto.bat à l'heure choisie.

Aussi fait rouler ClasseurAuto.bat par double clic pour voir la chose.
Quand tu voudras voir le code attend le message à l'écran puis fait Ctrl+Pause pour arrêter l'exécution.

Remarque : tu peux aussi mettre le classeur lui-même dans les tâches planifiées. L'avantage du fichier .bat c'est que tu pourras éventuellement ajouter des paramètres à l'ouverture du fichier.  Plus d'infos sur demande.

Cordialement,

Guy

Oui,

J'ai compris assez bien ce que tu cherches à faire.

Concernant mes remarques sur la tenue du code je crois important de cibler la chose surtout chez les débutants. Ayant bossé pour des firmes importantes, j'ai trop vu de codeurs auto-qualifié de gourous commettre des erreurs pitoyables et générer du code spaghetti à la pelle.

Les Activate et Select en surnombre dans le code trahissent l'utilisation intempestive de l'enregistreur de macro. Cet enregistreur est un outil extrêmement pratique cependant il ne sait pas écrire du code propre, ce n'est pas son but d'ailleurs. Une fois la macro automatiquement enregistrée par le truc il convient de nettoyer les Select et autres Activate par des références ciblées aux cellules, plages et feuille.

Par exemple lors de l'ajout d'une feuille dans un classeur Excel lui donne un nom de code générique, par exemple Feuil33. Rien, absolument rien n'empêche de nommer cette feuille TrucMachin comme nom de code et d'afficher dans l'onglet le même nom ou tout autre. À partir de là, des références comme TrucMachin.QuelqueChose.DeBienUtile.CommeUneRéférence.Explicite.EstPlusClair(PourLeCodeur).

Pour le fichier complet, si l'envie te prends de me l'envoyer, ne te gêne pas. Mon adresse de courriel est publique. Elle est inscrite dans mon profil.

2pme@sympatico.ca

Cordialement,

Guy

Bonjour,

Le classeur uht2.xls ne roule pas.
Feuille lundi A69:R71 = #VALEUR
Feuille Feuil20 une vingtaine de #REF

Dans le code
Bouton de la feuille lundi GRAPH -> Module1, fonction trier() "Variable non définie" : xlSortValues. AutoFilter n'a pas de méthode Sort. Et ActiveWorkbook.Worksheets("jeudi") donne évidemment des maux de tête au compilateur; pas de feuille "jeudi", néant, zéro, aucune.
Et pourquoi ActiveWorkBook, as-tu l'intention de travailler sur un autre classeur ailleurs dans le code?

Bouton de la feuille lundi RETOUR -> Module3, fonction RETOUR4() Sheets("ACCUEIL").Select "L'indice n'appartient pas à la sélection". Normal, pas de feuille "ACCUEIL".

Aussi, pourquoi écrire
    Range("C4").Select
    Selection.ClearContents
au lieu de Range("C4").Clearcontents

C'est une (mauvaise) habitude très répendue de cibler des plages en les activant et en les sélectionnant.
Au lieu d'écrire
Worksheets("toto").Activate
Worksheets("toto").Range("A1:IV35").Select
Selection.ClearContents

ne vaut-il pas mieux écrire, avec le nom de code de la feuille "toto" que nous supposerons être Machin :
Machin.Range("A1:IV35").ClearContents

De même
    Sheets("ACCUEIL").Select dans RETOUR4, Module3
sélectionne une feuille en vue d'un  traitement avec des Range("...").Quelquechose
Ce qui rend le code très difficile à suivre.
Alors que travailler directement avec le nom de code des feuilles simplifie grandement le débroussaillage du code et l'intention du codeur.

Machin.Range("A1:IV35").ClearContents cible directement la feuille au nom de code Machin alors que Range("A1:IV35").ClearContents rencontré ici ou là dans le code ne donne aucune information sur la feuille actuellement visée et entraine un effort considérable et bien inutile pour le réviseur de code.

Cordialement,

Guy

Ouais,

«Au niveau des États, l’application a été fonction des choix religieux . Les États catholiques, l’Espagne, la France, le Portugal, les États italiens l’ ont adopté immédiatement. Par contre, les États protestants refusèrent car ils ne voulaient pas reconnaître le pouvoir de l’Église catholique sur le temps . Ainsi, les États allemands ne l’ont adopté qu’en 1699 et l’Angleterre en 1752. Le monde orthodoxe aussi a retardé l’application du calendrier grégorien .En Russie, son adoption a été décidée par les Bolcheviques en 1918, après la révolution des 24-25 octobre...qui a eu lieu les 6 et 7 novembre 1917.

Aujourd’hui, le calendrier grégorien a été adopté dans le monde entier où il coexiste avec des calendriers religieux traditionnels.»

Dois-tu tenir compte de la date d'adoption dans les différentes contrées?
Si tel est le cas, comme je le crois, tu devras avoir sous la main le type de calendrier en usage avant l'adoption du calendrier grégorien.
Si ce calendrier précédent est le bon vieux calendrier julien, pas trop de problème. Autrement, Aouch!.
Le passage du calendrier julien au calendrier grégorien n'est pas si compliqué mais pour un calendrier autre que julien c'est l'enfer en vue.

Des calendrier mayas, égyptiens, perses, chinois ou autres en vue?

Guy

Re bonjour,

Je vois bien. Ma question est où et comment est formé le premier tableau?

Je dis bien le premier tableau, celui qui porte des enregistrement multiples (mal formés).

Que tu veuilles séparer les siamois des lignes du premier tableau est louable.
Cependant pourrais-tu m'expliquer qui, quoi, comment, forme ce premier tableau.

Le problème est là je crois.
Pondre du code pour réparer des machines à vapeur me semble peu productif.

Erre-je?

Guy

Bonjour,

Quand tu dis que tu es confronté à l'utilisation de FirstDayOfWeek.Monday, d'où tiens-tu ça?
Dans la liste des paramètres d'Application dont la liste est donnée dans le fichier d'aide à la méthode Application.International() il n'y a, concernant les date, rien qui ressemble à un paramètre fixe. Tu as donc tous loisirs d'écrire ta fonction avec le paramètre de ton choix.

  Resultat = DateDiff("ww", "01/03/01", "11/09/01", VbDayOfWeek.vbThursday, VbFirstWeekOfYear.vbFirstFullWeek)
  Resultat = DateDiff("ww", "01/03/01", "11/09/01", VbDayOfWeek.vbThursday, VbFirstWeekOfYear.vbFirstJan1)
  Resultat = DateDiff("ww", "01/03/01", "11/09/01", VbDayOfWeek.vbSunday, VbFirstWeekOfYear.vbFirstFullWeek)
  Resultat = DateDiff("ww", "01/03/01", "11/09/01", VbDayOfWeek.vbMonday, VbFirstWeekOfYear.vbFirstJan1)


Ou toute autre combinaison. L'énumération VbDayOfWeek n'a rien à voir avec un quelconque paramètre d'Application.

Me trompe-je?

Guy

Date et heure

Index	Type	Signification
xI24HourClock	Boolean	True pour le format 24 heures, False pour le format 12 heures.
xI4DigitYears	Boolean	True si les années comportent quatre chiffres, False si elles comportent deux chiffres.
xIDateOrder	Long	Ordre des éléments de la date : 0 = mois-jour-année 1 = jour-mois-année 2 = année-mois-jour
xIDateSeparator	String	Séparateur de date (/ ).
xIDayCode	String	Symbole du jour (j).
xIDayLeadingZero	Boolean	True si un zéro est affiché à gauche dans les jours.
xIHourCode	String	Symbole des heures (h).
xIMDY	Boolean	True si la date complète utilise l'ordre mois-jour-année, False si elle utilise l'ordre jour-mois-année.
xIMinuteCode	String	Symbole des minutes (m).
xIMonthCode	String	Symbole du mois (m).
xIMonthLeadingZero	Boolean	True si un zéro est affiché à gauche dans les mois (lorsque les mois sont affichés sous forme numérique).
xIMonthNameChars	Long	Cette propriété renvoie toujours trois caractères pour la compatibilité amont. Les noms de mois courts sont lus à partir de Microsoft Windows et peuvent avoir n'importe quelle longueur.
xISecondCode	String	Symbole des secondes (s).
xITimeSeparator	String	Séparateur d'heure (:).
xITimeLeadingZero	Boolean	True si un zéro est affiché à gauche dans l'heure.
xIWeekdayNameChars	Long	Cette propriété renvoie toujours trois caractères pour la compatibilité amont. Les noms de jours courts sont lus à partir de Microsoft Windows et peuvent avoir n'importe quelle longueur.
xIYearCode	String	Symbole de l'année dans les formats numériques (a).

Bonjour,

Ce que  j'aperçois (enfin) à la vue des classeurs c'est que le tableau initial est mal formé.

Les lignes du tableau initial portent plusieurs enregistrements au sens des enregistrements d'une base de données bien formée, donc sont mal formés «quand il y a plusieurs numéro sur la même ligne».

Or, il ne devrait pas y avoir «plusieurs numéro sur la même ligne».

Le but de cet exercice est de "bien former" chaque enregistrement.

Alors,
question 1 : d'où vient le tableau initial?
question 2 : n'y a-t-il moyen que le tableau initial soit d'emblée bien formé?
question 3 : pourquoi faire compliqué quand on peut faire simple?

Maxime (bis) «Think first, code later.»

Guy