Discussion :

[Wyzzart]

Bonjour!

Je stocke dans un dossier, des fichiers .xlsm, ceux-ci ont pour format " date_nom_numeroincrementéàchaqueenregistrementdufichier ".

Je souhaiterai, suite à l'appui sur un qpushbutton, ouvrir le fichier avec le numéro incrémenté le plus élevé.
Pourriez-vous, s'il vous plait, m'aiguiller sur la méthode à suivre?

Je suppose qu'un split va intervenir, un QIODevice::ReadOnly aussi mais je ne sais pas comment organiser tout ça et surtout comment " spliter" correctement les noms de tous mes fichiers présents dans ce dossier....


Merci d'avance pour vos réponses!

[koala01]

Salut,

Le nom d'un fichier n'est jamais qu'un chaine de caractères qui est fournie pour en permettre l'ouverture.

En utilisant la classe QDir et sa fonction entryList sous une forme qui pourrait être proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
QDir myDir{"chemin_vers_le_dossier_contenant_tes_fichiers"};
auto files = myDir.entryList(QDir::files, QDir::Name |QDir::Reversed); // je ne veux que les fichiers, triés par nom, dans l'ordre inverse

Vu qu'une date du jour convertie en chaine de caractères (au format "américain", à savoir l'année suivi du mois puis du jour) représente une chaine de caractères "plus grande" que la date d'hier, tu ***devrais*** (si tes noms de fichiers sont bel et bien au format YYY-MM-DD_numero) retrouver les fichiers créés aujourd'hui avant ceux d'hyier dans la QStringList renvoyée par cette fonction.

Et comme "numéro" est une valeur incrémentée à chaque fois, le dernier fichier ajouté ** devrait ** être le premier de la liste. Pas mal non

A partir de là, il devrait suffire de prendre la première valeur de cette QStringList (en utilisant la fonction at(0), par exemple) pour déterminer le nom du fichier que tu veux ouvrir.

Autrement dit, si tu crées un slot connecté sur le signal "clicked" de ton bouton sous la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
void MyClass::onOpenButtonClicked(){
    QDir myDir{"chemin_vers_le_dossier_contenant_tes_fichiers"};
    auto allFiles = myDir.entryList(QDir::files, QDir::Name |QDir::Reversed);
    QFile toOpen{allFiles.at(0)};
    if(! toOpen.open(QIODevice::ReadOnly)){ // mode d'ouverture à adapter à tes besoins ;)
       // cela n'aurait jamais du arriver, afficher un message serait pas mal avant de quitter ;)
       return;
    }
   /* le fichier est ouvert ... on peut passer à la suite */
}

tu devrais arriver à ce que tu demandes (note qu'il faudra voir s'il ne faut pas concaténer le nom du dossier avec le nom du fichier pour que cela puisse fonctionner )

[Bktero]

Bonjour,

Récupérer la liste des fichiers, la trier par ordre alphabétique, prendre le dernier fichier ? Selon comment ton numéro de version est formaté, ça peut fonctionner (000....999 -> OK ; 0...999 --> KO).

[Wyzzart]

WOOOOOOOW *.*

Je n'avais vraiment pas du tout pensé à cette solution!

Merci beaucoup de votre aide!
(J''essaye de mettre en place cette solution et dès que ceci est fait je passe le sujet en "résolu" )

[koala01]

Bonjour,

Récupérer la liste des fichiers, la trier par ordre alphabétique, prendre le dernier fichier ? Selon comment ton numéro de version est formaté, ça peut fonctionner (000....999 -> OK ; 0...999 --> KO).

Oui, mais ce sera moins sensible que le problème de la date, parce que le tout premier test effectué porte sur la longueur de la chaine de caractères: un chaine de 3 caractères sera d'office plus petite qu'une chaine de 4

Le véritable problème se posera au niveau du format utilisé pour la date, car, si on code uniquement les caractères représentatifs (par exemple 112012 pour représenter le premier janvier 2012) une date "plus récente sera considérée comme "plus petite" qu'une date plus ancienne qui nécessiterait plus de caractères (par exemple 31122010 pour représenter le 31 décembre 2010).

Il faut donc que le jour et le mois soient tous les deux codés sur deux chiffres, indépendamment d'un éventuel caractère de séparation, de manière à ce que l'on travaille systématiquement sur une chaine de caractères composée de 8 caractères (plus les éventuels caractères de séparation).

Mais cela ne résoudrait qu'une partie du problème, parce que les tests suivants portent systématiquement sur la valeur de chaque caractères, dans l'ordre dans lequel ils arrivent: on test d'abord le premier caractère des deux chaines, puis le deuxième, et ainsi de suite jusqu'à la fin de la chaine. Et dés qu'un caractère diffère d'une chaine à l'autre, on a la réponse que l'on cherchait.

le format "jour-mois-annee" ("JJ-MM-AAAA") posera donc un problème, car on se retrouve de nouveau avec la possibilité d'avoir une date plus récente (exemple 01-01-2012) qui soit considérée comme "plus petite" qu'une date plus ancienne (exemple 31-12-2010), vu que le premier chiffre donnera la réponse.

Pour éviter ce problème, il faut impérativement que l'année soit codée en premier, suivie du mois, et enfin du jour. De cette manière, l'année sera "prioritaire" dans le test, si bien qu'une date de l'année 2012 sera toujours plus grande qu'une date de l'année 2010, et que si les deux dates sont de la même année, on en vienne à coder le mois de l'année, si bien qu'une date du mois de fevrier 2012 (2012-02-xx) sera toujours plus grande qu'une date du mois de janvier de la même année (21012-01-xx). Enfin, si l'année et le mois corresponde, ce sera le jour qui sera pris en compte, si bien que le lendemain sera toujours plus grand que sa veille

Le seul impératif est donc bel et bien de commencer par une date de taille fixe (8 caractères significatifs, plus séparateurs éventuels) et dont le format prenne l'année en premier, suivie du mois et enfin du jour pour que le tri puisse être correct

EDIT: Ce n'est qu'une fois que nous nous serons assurés que la date ne risque pas de "foutre le bordel" dans le tri, que le problème du numéro de fichier se posera. Et encore, tout dépend de si on décide de remettre ce numéro à 0 tous les jours, ou si l'on décide de continuer la numérotation de jours en jours.

En effet, si l'on décide de poursuivre la numérotation de jour en jour (que le premier numéro d'un jour donné correspond au dernier numéro de la veille +1), le problème de la taille du numéro ne se pose pas.

Car, dans le pire des cas (du moins, avant d'avoir dépassé les quatre milliards, si le numéro peut-être représenté par un entier de 32 bits), la taille totale de la chaine de caractères sera augmentée lorsque l'on en vient à multiplier le nombre par dix, si bien que la chaine de caractères correspondant au numéro 100 sera toujours plus grande que la chaine de caractères correspondant au numéro 99 (et à tous ceux qui précèdent).

Le problème se posera si on remet le compteur de fichier à 0 tous les jours, car, dans ce cas, le premier fichier d'un jour donné, portant -- a priori -- le numéro 1 pourrait être considéré comme "plus petit" que le dernier fichier de la veille (sans doute composé d'un nombre à deux, trois ou quatre chiffres). A ce moment là, il faut effectivement prévoir de représenter le numéro du fichier sous la forme d'un nombre de chiffres non significatifs (autrement dit, sous une forme proche de 0000x pour les unités) suffisant pour éviter l'augmentation de la taille de la chaine de caractères pour n'importe quel fichiers, ce qui implique d'évaluer avec "un minimum de précision" le nombre de fichiers qui seront créés tous les jours

[Bktero]

J'avais supposé la date au format AAAAMMJJ (osef des séparateurs éventuels).

Le problème que tu décris est le même que celui que j'évoque sur le format du numéro de version.

parce que le tout premier test effectué porte sur la longueur de la chaine de caractères: un chaine de 3 caractères sera d'office plus petite qu'une chaîne de 4

Ça dépend de la méthode de tri des fichiers.

12.txt est avant 2.txt dans l'explorateur de fichiers de Windows / idem avec ls dans PowerShell sous Windows / idem avec Bash ici

[koala01]

J'avais supposé la date au format AAAAMMJJ (osef des séparateurs éventuels).

Bien sur qu'osef des caractères éventuels... C'est bien pour cela que je n'en ai parlé qu'entre parenthèse

Mais, si je ne les avais pas signalés, "on" aurait trouvé le moyen de pinailler sur mon intervention en prétextant que je n'en avais pas tenu compte

Ça dépend de la méthode de tri des fichiers.

12.txt est avant 2.txt dans l'explorateur de fichiers de Windows / idem avec ls dans PowerShell sous Windows / idem avec Bash ici

De fait ... Et je t'avoue que, sur ce coup, je ne sais pas trop quelle est la méthode de tri utilisée par la fonction entityList

Dans le pire des cas, une fois que l'on a la liste des noms, rien ne nous empêche de refaire un tri de cette liste par ordre décroissant, histoire d'être sur que le premier de la liste soit bel et bien le dernier créé

(et sinon, je me demande même s'il n'y a pas moyen de demander le tri par date de création / modifications )

[Wyzzart]

Oui, mais ce sera moins sensible que le problème de la date, parce que le tout premier test effectué porte sur la longueur de la chaine de caractères: un chaine de 3 caractères sera d'office plus petite qu'une chaine de 4

Le véritable problème se posera au niveau du format utilisé pour la date, car, si on code uniquement les caractères représentatifs (par exemple 112012 pour représenter le premier janvier 2012) une date "plus récente sera considérée comme "plus petite" qu'une date plus ancienne qui nécessiterait plus de caractères (par exemple 31122010 pour représenter le 31 décembre 2010).

Il faut donc que le jour et le mois soient tous les deux codés sur deux chiffres, indépendamment d'un éventuel caractère de séparation, de manière à ce que l'on travaille systématiquement sur une chaine de caractères composée de 8 caractères (plus les éventuels caractères de séparation).

Mais cela ne résoudrait qu'une partie du problème, parce que les tests suivants portent systématiquement sur la valeur de chaque caractères, dans l'ordre dans lequel ils arrivent: on test d'abord le premier caractère des deux chaines, puis le deuxième, et ainsi de suite jusqu'à la fin de la chaine. Et dés qu'un caractère diffère d'une chaine à l'autre, on a la réponse que l'on cherchait.

le format "jour-mois-annee" ("JJ-MM-AAAA") posera donc un problème, car on se retrouve de nouveau avec la possibilité d'avoir une date plus récente (exemple 01-01-2012) qui soit considérée comme "plus petite" qu'une date plus ancienne (exemple 31-12-2010), vu que le premier chiffre donnera la réponse.

Pour éviter ce problème, il faut impérativement que l'année soit codée en premier, suivie du mois, et enfin du jour. De cette manière, l'année sera "prioritaire" dans le test, si bien qu'une date de l'année 2012 sera toujours plus grande qu'une date de l'année 2010, et que si les deux dates sont de la même année, on en vienne à coder le mois de l'année, si bien qu'une date du mois de fevrier 2012 (2012-02-xx) sera toujours plus grande qu'une date du mois de janvier de la même année (21012-01-xx). Enfin, si l'année et le mois corresponde, ce sera le jour qui sera pris en compte, si bien que le lendemain sera toujours plus grand que sa veille

Le seul impératif est donc bel et bien de commencer par une date de taille fixe (8 caractères significatifs, plus séparateurs éventuels) et dont le format prenne l'année en premier, suivie du mois et enfin du jour pour que le tri puisse être correct

EDIT: Ce n'est qu'une fois que nous nous serons assurés que la date ne risque pas de "foutre le bordel" dans le tri, que le problème du numéro de fichier se posera. Et encore, tout dépend de si on décide de remettre ce numéro à 0 tous les jours, ou si l'on décide de continuer la numérotation de jours en jours.

En effet, si l'on décide de poursuivre la numérotation de jour en jour (que le premier numéro d'un jour donné correspond au dernier numéro de la veille +1), le problème de la taille du numéro ne se pose pas.

Car, dans le pire des cas (du moins, avant d'avoir dépassé les quatre milliards, si le numéro peut-être représenté par un entier de 32 bits), la taille totale de la chaine de caractères sera augmentée lorsque l'on en vient à multiplier le nombre par dix, si bien que la chaine de caractères correspondant au numéro 100 sera toujours plus grande que la chaine de caractères correspondant au numéro 99 (et à tous ceux qui précèdent).

Le problème se posera si on remet le compteur de fichier à 0 tous les jours, car, dans ce cas, le premier fichier d'un jour donné, portant -- a priori -- le numéro 1 pourrait être considéré comme "plus petit" que le dernier fichier de la veille (sans doute composé d'un nombre à deux, trois ou quatre chiffres). A ce moment là, il faut effectivement prévoir de représenter le numéro du fichier sous la forme d'un nombre de chiffres non significatifs (autrement dit, sous une forme proche de 0000x pour les unités) suffisant pour éviter l'augmentation de la taille de la chaine de caractères pour n'importe quel fichiers, ce qui implique d'évaluer avec "un minimum de précision" le nombre de fichiers qui seront créés tous les jours

Bonjour,

Ce format est géré par du vba directement dans le fichier excel

Par contre j'ai rencontré un problème lors de la mise en place du code.. Lorsque que je clique sur mon bouton, mon programme crash.. Et j'obtiens cette erreur:

ASSERT failure in QList<T>::at: "index out of range", file C:\Qt\5.13.0\mingw73_32\include/QtCore/qlist.h, line 560

Mais je vois pas en quoi l'index 0 est en dehors de la plage...

[Invité]

Bonsoir,

Code Qt :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
auto allFiles = myDir.entryList(QDir::files, QDir::Name |QDir::Reversed);
// TODO : s'assurer que 'allFiles' contient au moins un fichier, ce qui nous permettra l'accès 'allFiles.at(0)' qui suit :
QFile toOpen{allFiles.at(0)};

[Wyzzart]

Bonjour veuillez pardonner mon temps de réponse,

J'ai bien essayé de mettre tout ça en place mais le problème que je rencontre est le fait qu'il ne se passe rien quand je clique sur le bouton..