Extraire les données des lignes; les séparer en colonnes
Je comprend que cela va t'agacer que les choses ont été modifiées entre temps ...
Par contre, pour faciliter la vérification, je préfère que les lignes vides ou contenant "Rien" ne soient pas supprimées.
J'ai un code qui le fera;
Tu voudrais donc maintenant me faire faire ce que je m'apprêtais à faire dès le départ, après m'avoir intimé de ne pas le faire !
Quant au séparateur "A:", en cas d'absence il faudra le remplacer par un autre ! Sans doute "/" si sa présence est récurrente...
cher ami,
Oui oui, je sais ... comme dit l'adage, il n'y a que les idiots qui ne changent pas d'avis !
Mon projet a beaucoup évolué; j'ai réussi à tout faire ... sauf que ma méthodologie est très très basique,
Ce que je te propose, laisse moi épurer les données (de confidentialité) et je t'envoie le fichier pour avoir ton opinion et pour voir comment tu aurais fait ... ce n'est pas indispensable ... c'est pour mon éducation.
Comme je t'ai déjà dit je ne suis pas un férue de la programmation ... mais ça me plait ... et je voudrai évoluer en comprenant ce que je fais ... ce n'est pas indispensable dans ma profession ... c'est mon passe temps. Certains font du sport ... moi ce sont les mathématiques et la programmation (même si en programmation, mon niveau est très très bas
Pour le fichier, si tu l'as modifié, je suis bien sur preneur!
A bientôt
Il me faut un modèle nouvelle formule pour définir tout ce qui est à modifier...
Mais c'est toujours un mauvais calcul que d'apporter des modifications par étapes, le programme établi, le modifier ne prend pas moins de temps que l'écrire initialement, et parfois plus.
Hello,
Non rassures toi, il n'y a rien à modifier. Mon système fonctionne très bien. Sauf que, comme ci, pour aller à Paris de Nantes, je passe par Marseille .... alors que c'est sur c'est mieux de passer par Angers
Dès que j'ai mis de l'ordre dans tout ça je te l'envoie ... j'y suis avec !
Merci
A bientôt
re Hello
Je t'envoie le fichier.
Dans la 1ère feuille j'ai mis la liste (un échantillon) en colonne A.
Le travail se fait en feuille 2.
Ainsi je peux re utiliser cette liste pour les tests.
Pour mes tests, je copie colonne A en feuille 1 vers colonne C en feuille 2
Ensuite je clique sur chaque bouton selon l'ordre.
Bien sur dans sa version finale, il y aura un seul bouton qui fera appel à tous ces boutons par la fonction Call.
En colonne I / feuille 2 : durée de chaque intervention en minutes.
J'aimerai bien utiliser ton programme ... mais je ne comprends pas tout!
Si tu peux l'actualiser pour que je puisse faire comme je t'ai expliqué :
je mets toute la liste en vrac en colonne 3 de feuille 2
(on oublie le RIEN!)
j'utiliserai ton programme tout en essayant de le décortiquer à mon aise
Il me reste un dernier problème à régler :
en feuille 2, après le 14e bouton,
j'aimerai parcourir la liste pour vérifier s'il y a une date exemple en C1, C3, C14 ...
chaque fois que je vois une date, je la copie en colonne A et B, décalée d'une ligne
donc date de C1 va à A2 et B2, et A3 et B3
jusqu'à la prochaine date
date de C3 va à A4 et B4, et A5 et B5 etc jusqu'à A13 et B13
date de C14 va à A15 et B15 etc...
en formatant colonne A : jour (jjjj)
et colonne B ; date jj/mm/aaaa
et terminer par supprimer la ligne des dates C1 C3 C14 ...
Si tu peux me faciliter cette tache ce sera super.
Merci.
A bientôt
Bonjour,
Je ne vois pas trop ce que je pourrais adapter !
Pour ton information, dans ce que j'ai vu (ton dernier post et fichier) :
Call n'est pas une fonction (une fonction renvoie un résultat...) mais une instruction permettant d'appeler une procédure, dont l'utilisation n'est en aucun cas obligatoire.
Son utilisation implique par contre que les arguments de la procédure (si arguments il y a) soient mis entre parenthèses, alors que l'appel d'une procédure sans utiliser Call exige au contraire que les arguments ne soient pas mis entre parenthèses.
A noter aussi que l'appel d'une procédure Function avec Call fait perdre le renvoi du résultat de la fonction...
L'intérêt de son utilisation est donc à peu près nul, sinon inutilement contraignant.
Vu une recherche avec Find : lancée sur toute la feuille avec Cells alors que ta recherche se limite à une colonne ! et avec un bonne partie des paramètres inutiles...
Variant est le type par défaut d'une variable lorsqu'on ne la type pas. Il n'est donc guère utile de typer Variant ! Mais de plus, là où tu types une variable Cell comme Variant, cette dernière n'apparaît nulle part dans le code exécutable ! Déclaration gratuite, alors que tu utilises 3 variables non déclarées (qui seront donc de type Variant), dont 2 en tant que String et 1 en tant qu'Integer...
Tu reviens à une imitation de l'enregistreur avec un code type : plage.Select : Selection.ClearContents ! plage.ClearContents évitait ce détour inutile.
Cordialement.
Bonjour,
Moi qui croyais que ma méthodologie allait t'épater ... mais bof ...
Donc je reviens vers toi car j'aimerai bien passer vers une autre dimension. En effet, je raisonne de façon visuelle alors que toi, tu vois le problème dans son ensemble en virtuel pour aboutir aux résultats.
Oublions les explications données auparavant pour ne pas se perdre. Je t'envoie 1 fiche comprenant deux feuilles:
feuille 1 : données brutes
feuille 2 : données travaillées
dans feuille 2:
la 1ère ligne comprend les titres
Merci pour ton aide
Je regarderai !
Cordialement.
Hello,
Pas de souci. J'espère que ton problème de santé trouve une solution. Je suppose que tu as deviné que je suis chirurgien orthopédiste
Bon courage pour demain
Amitiés
Il faut toujours convertir une date en Date ! CDate y suffit normalement. Sinon VBA convertit mais à sa façon (américaine).
L'action de convertir oblige VBA à se référer aux paramètres régionaux du système pour interpréter la date...
Hello,
J'ai vu. Tu l'avais expliqué ... mais je n'arrive pas. La date a été rentrée en format texte : dimanche 12/10/2016. Je l'ai séparée en dimanche dans une colonne et en 12/10/2017 dans une autre colonne. Mais elle apparaît comme 10/12/2017. Pourquoi ? Excel m'aime pas !!!
Bon il est tard pour nous ... on va à l'hôpital demain ... toi en voiture et moi à vélo !
Bon courage pour demain
Amitiés
Test !
En A1 texte : Dimanche 12/10/2017
Procédure :
Sub ConverDate()
Dim d
With ActiveSheet
d = Split(.Range("A1"))
d = DateValue(d(1))
MsgBox d
.Range("D1") = d
End With
End SubTu testes en cliquant sur le bouton ! La date sera affichée dans un message, puis affectée à D1.
Je te conseille de vérifier le format de cellule de D1 avant de cliquer, et ensuite une fois la date affectée, pour bien voir comment Excel procède lorsqu'une date est affectée ou saisie. Le format de cellule n'est pas mis par VBA comme tu vois. En VBA on ne fait que la conversion avec DateValue, fonction qui renvoie une date à partir d'un texte identifiable comme date. (Comme CDate, elle force VBA à se référer aux paramètres régionaux).
hello,
J'espère que ta journée a été OK.
J'ai essayé ta formule elle marche parfaitement.
Merci cher ami.
Bien sur, puisque mon programme est haché, il est un peu lent! Tant pis.
Maintenant je vais créer un TCD pour analyser les données.
Je savais le faire mais j'ai un peu oublié.
Je vais le re étudier.
Merci encore pour tout.
Amitiés
Bonsoir, ou Bonjour,
Cela aurait pu être pire, j'ai réussi à éviter d'être bloqué (un peu de chance !) mais pas tous les bouchons quand même. La journée a été un peu longue et j'ai été somnolent une partie de la soirée...
J'entamerai la construction détaillée de ton code intervention demain, en espérant qu'ensuite tu te rangeras à des solutions plus rapides...
Pour les TCD, je ne serai sûrement pas le meilleur conseil, mais il y a des intervenants qui maîtrisent parfaitement cette activité...
A+
Bonjour,
Au fait, non, j'ignorais que tu étais chirurgien... Le fait de manipuler des données relative à des interventions chirurgicales n'impliquent pas d'être chirurgien...
Avant d'opérer on fait un diagnostic, qui permet de choisir ce qu'il y a lieu de faire, et savoir où l'on va lors de l'opération. Traiter des données implique pareillement un "diagnostic" de façon à bien définir où l'on veut aller, ce que l'on veut obtenir...
Lorsque l'on construit un outil destiné à être utilisé ensuite, la conception du projet prend de l'importance en ce sens que les fonctionnalités de l'outil que l'on n'a pas envisagé et prévu de réaliser au départ ne se retrouveront pas à l'arrivée, et il l'on veut obtenir un outil qui devra remplir plusieurs fonctions, il convient lors de la conception de voir comment ces diverses fonctions pourront être remplies simultanément...
Dans ton cas la question est plus simple au départ, il s'agit de prendre des données reçues sous une forme donnée et de les traiter de façon à en restituer les éléments qui sont pertinents pour toi, pouvoir les consulter et les utiliser...
Il n'y a donc pas lieu de se lancer dans une conception particulièrement élaboré mais il convient de cerner tous les éléments de la question.
La question posée :
Traiter des lignes de texte rassemblées dans une feuille, en colonne A, pour en tirer les données relatives à des interventions chirurgicales, et les réorganiser en tableau.
Le tableau comprendra une ligne par intervention, les éléments descriptifs à recueillir pour chaque intervention seront répartis selon 7 champs (colonnes du tableau) : Date - Salle - Service - Urg./Progr. (Urgence ou Programmée) - Chirurgien - Heure (de début) - Durée.
On a ainsi défini l'objectif en termes de résultat à obtenir à partir d'éléments fournis au départ. A partir de là, il convient d'approfondir l'analyse des données reçues à traiter, pour établir la méthodologie de traitement qui permettra d'atteindre l'objectif, en plusieurs niveaux : vue générale de la méthode concernant l'ensemble des données à extraire en vue du résultat final, éléments de méthode propres à certaines données seulement, qui se regroupent selon les emplacements où on les trouvera, détails concernant chaque donnée individuellement, selon ses particularités...
A ce stade, où seul l'objectif est pratiquement défini, je reprends naturellement ce que tu as arrêté : produire un tableau des interventions à partir de données brutes. Avec une petite différence : je ne retiens pas la duplication de deux champs de données, la date et la durée. Cela n'ajoute rien, l'information est présente et n'a pas besoin d'être doublée, ce qui n'est qu'un alourdissement inutile.
Pour la date, vouloir la mettre une fois sous le format jj/mm/aaaa et une seconde fois sous le format jjjj est d'autant plus absurde qu'en mettant la cellule au format : jjjj jj/mm/aaaa on obtiendra exactement la même information visuelle sans duplication.
Pour la durée, l'affichage logique en h:mm apporte l'information voulue. La traduire simultanément en minutes n'apporte rien de plus, c'est moins parlant immédiatement, mais l'on peut tout de même faire l'opération de conversion mentalement de façon très brève (de l'ordre de la seconde). Le format de cellule [m] afficherait l'information en minutes (la même valeur horaire dans la cellule).
Au stade de l'extraction et présentation des données en tableau, on dispose de la durée en valeur horaire, ce qui est suffisant à ce niveau. J'accepte volontiers qu'un travail sur les données pourra exiger que la durée soit exprimée en minutes (ce que l'on obtient en multipliant la valeur horaire par 1440 [il y a 1440 minutes dans 1 jour, le jour étant l'unité de valeur horaire et date d'Excel]). Mais c'est alors dans ce nouveau tableau de travail qu'il sera loisible de fournir un champ durée exprimé en unités minute. Au niveau extraction, c'est redondant.
On va pouvoir maintenant se pencher sur les données à extraire du texte brut fourni, et d'abord comment les localiser...
Je poursuis donc sur la méthodologie qui permettra de réaliser l'objectif fixé.
Nous avons donc à construire un tableau dont chaque ligne décrira une intervention. Cette description de chaque intervention rassemble des données informatives sur 7 champs (colonnes). On construit donc un tableau à 7 colonnes, dont le nombre de lignes variera selon le nombre d'interventions trouvées dans le texte source reçu (et on réservera une première ligne pour les intitulés d'en-tête des champs).
Le texte source consiste en un certain nombre de lignes de texte sur une feuille Excel, dans une seule colonne. il s'agira donc de détecter les lignes de texte contenant les informations cherchées relatives à chaque intervention et les extraire pour les réorganiser dans le tableau cible.
Ce que l'on sait :
- Chaque intervention individuelle figure sur une ligne de texte qui contient le service impliqué, le nom du chirurgien et la durée, soit 3 des informations recherchées.
- Si l'intervention est programmée, la ligne débute par l'heure, sinon l'indication (urgence) figure en début de ligne. Et si l'information est de type Urgence, l'heure en figure isolée à la ligne précédente. Voilà qui nous fournit 2 informations supplémentaires parmi celle recherchées, le type et l'heure.
A partir de là donc, lorsqu'on rencontrera une ligne débutant par une heure, il s'agit d'une heure d'intervention.
On trouvera pour cette intervention le service, le chirurgien et la durée sur la ligne 'heure' si programmée, sur la ligne en-dessous si urgence.
- La salle de l'intervention figure elle sur une des lignes précédant la ligne intervention et débutant par Salle x, x étant le numéro de la salle.
- De même, la date de l'intervention figure sur une des lignes précédentes sous la forme : Jour de la semaine (Lundi, Mardi... Dimanche) suivie de la date [Joursem jj/mm/aaaa].
Ainsi donc, lorsqu'on rencontrera une ligne 'date' ou une ligne 'salle', pour les interventions que l'on trouvera ensuite, ce sera la date de l'intervention et la salle de l'intervention, jusqu'à ce qu'une autre ligne 'date' substitue une nouvelle date à la précédente ou qu'une autre ligne 'salle' substitue une autre salle à la précédente.
- Les autres lignes de texte que l'on peut trouver débutent par diverses mentions : Remise en condition, Saisie le, Salle externe ou sont vides. Pour l'indication Salle externe, pas d'intervention qui suit, il y a donc lieu de les exclure.
- On note aussi que de nombreuses lignes débutent en fait par des espaces (dont la ligne débutant par l'heure de l'intervention). Il conviendra d'en tenir compte.
Cet examen du texte source permet d'arrêter la méthodologie du traitement à opérer pour réaliser l'opération souhaitée.
Méthodologie retenue :
• Tableau dynamique de type (colonnes, lignes) [lignes en 2e dimension car le nombre de lignes variera alors que le nombre de colonnes est fixe], que l'on incrémentera d'une ligne pour chaque intervention trouvée, de façon à l'y consigner.
• Parcours des lignes du texte (en col. A, jusqu'à la dernière que l'on aura préalablement définie), dont on examinera le texte après élimination des espaces à gauche, de façon à détecter les lignes correspondant à une interventions ou fournissant une information relative aux interventions.
• Si la ligne n'est pas vide :
- ligne commençant par : remise ou saisie ou salle externe : on passe,
- ligne commençant par une date (question relative à la détection de la date à voir plus loin... !) : on recueille la date et la conserve pour les opérations qui surviendront,
- ligne commençant par salle [on aura déjà éliminé l'indication salle externe] : on recueille le numéro de la salle, à conserver sous la forme 'S' suivi du numéro (indication voulue sous cette forme) pour les opérations à venir à la suite.
- ligne commençant par une heure [texte correspondant au modèle : ##:##] : on initialise une nouvelle ligne du tableau pour y saisir une intervention (dont on aura déjà normalement la date et la salle) et on teste la ligne au-dessous :
- - si la ligne au-dessous contient urgence, on enregistre le type et on passe à la ligne en-dessous,
- - sinon, on enregistre également le type et on reste sur la ligne,
[Par sécurité, pour éviter des problèmes de variations de casse inopinés, on opèrera les tests en basculant en minuscules le texte de la ligne examiné.]
Il y a logiquement plus de lignes d'interventions que de ligne salle utiles, et a-fortiori que de lignes dates, l'ordre des tests sur les lignes non vides sera donc plus optimal dans cet ordre : détection lignes à ignorer, détection lignes d'interventions (heure), détection lignes salle, détection lignes date.
• On poursuit ainsi jusqu'à la fin du texte, et l'on disposera alors d'un tableau des interventions tel que souhaité, qu'il suffira donc de compléter par des en-têtes, et d'affecter où on le souhaite (pour le voir !), et éventuellement de le mettre en forme si on le souhaite.
NB- La réflexion préalable doit viser le véritable objectif visé : soit en l'occurrence un tableau de toutes les interventions contenues dans le texte à traiter. Non, des lignes relatives à chaque intervention à inscrire l'une après l'autre, encore moins des informations isolées à extraire pour les rassembler par la suite... Il est évidemment plus économique et plus rapide de constituer d'emblée le tableau final que de passer par une quantité d'étapes intermédiaires. Plus rapide surtout si l'on veille à ne rien écrire dans une feuille Excel tant qu'on n'y est pas obligé, à extraire dans une variable tout élément à examiner dès lors que les opérations relatives à cet examen dépasse une. Si des difficultés ne permettent pas de s'en tenir rigoureusement à ce programme, il convient d'en rester le plus près possible...
Si on a définit une méthode de traitement, on n'a toutefois pas résolu toutes les questions liées à l'extraction des données utiles, qu'il va donc falloir dans un second temps examiner donnée par donnée (il n'y en a que 7 !).
Mais on a toutefois déjà défini (implicitement au moins) toutes les variables dont on aura besoin dans la procédure de traitement lorsqu'on passera à l'écriture. On peut donc les récapituler (et par la même occasion choisir les noms...) :
Itv() : tableau dynamique [Itv comme Interventions !], qu'on laissera de type Variant (les données qu'il doit accueillir comportent différents types)
i : variable Integer [i comme intervention !!], destinée à l'incrémentation en lignes du tableau
[On opèrera les dimensionnements successifs du tableau après incrémentation de i, sous la forme : Redim Preserve Itv(6, i), les indices allant alors de 0 à 6 et 0 à i.]
ln : variable Integer [ln comme ligne ou line !], variable de la boucle de parcours des lignes du texte
dln : variable Integer [dln comme dernière ligne !!], ligne de fin du texte à examiner
lgn : variable String [lgn comme ligne !!!], destinée à recueillir chaque ligne de texte avant de la tester
s : variable String [s comme salle !], destinée à conserver la salle d'intervention en cours
d : variable laissée de type Variant [d comme date !], destinée à conserver la date en cours.
On aurait pu typer d de type Date, toutefois ne pas typer une variable destinée à accueillir une date garantit que l'on ne se heurtera pas à une incompatibilité de type selon la valeur représentant une date que l'on peut être susceptible d'affecter : String pour un littéral date, Long pour un numéro de série date, Single pour un numéro de série date incluant une heure, et Date !
A ce stade, l'on n'a pas encore écrit la première ligne de code, mais on dispose déjà de la structure de la procédure à écrire. Sans anticiper sur l'étape suivante d'examen du recueil de chaque donnée, on peut imaginer que si le prélèvement peut s'opérer sans traitement particulier il suffira de l'affecter dans le déroulement de la procédure ébauchée. Mais dans le cas où une manoeuvre d'extraction particulière serait à réaliser, plutôt que d'alourdir la procédure de base, on pourrait externaliser ces opérations spécifiques dans des procédures annexes Sub ou Function (plus utilement Function sans doute, qu'il suffira d'appeler à partir de la procédure principale pour réaliser l'affectation). On conserverait ainsi une plus grande clarté au traitement opéré...
Il ne s'agit pas de traitement éclaté dans des procédures qu'il faudrait exécuter tour à tour, mais d'une programmation homogène modulée en une procédure principale et des procédures secondaires dédiées aux aspects particuliers du traitement auxquelles la procédure principale fait appel chaque fois qu'un traitement de l'espèce est à opérer, cela n'optimise pas plus le traitement global mais cela ne l'affecte pas non plus, et on gagne en clarté du code écrit qui sera plus facile à lire, interpréter et modifier s'il y a lieu.
A suivre.
Hello,
Wow, c'est bien expliqué et j'apprécie.
Concernant le début de la synthèse, je suis d'accord avec toi. Par contre j'aimerai t'illustrer quelque chose.
Nous avons de plus en plus de patients qui nous consultent pour un problème et ils savent déjà le traitement ... ou du moins qui ils croient savoir. Parce qu'ils ont googlelisé leurs pathologies et ils ont surfé sur tous les forums ... et en quelques minutes ils sont devenus chirurgiens ... alors que pour moi, cela m'a pris 13 ans d'études post bac .... et même là il m'a fallu 2 ans d'assistanat en CHU et encore quelques années d'accompagnement avant que je puisse dire à mon patient : vous avez ça et il va va falloir faire et ça et pas ça. Le plus difficile ce n'est pas de savoir ce qu'il faut faire ... mais de savoir ce qu'il ne faut pas faire et pourquoi. Tout ça sous entend que l'on dispose de connaissances suffisantes : qu'est ce qu'il a ? quels examens demander? pourquoi? qu'est-ce que je peux faire? comment je les ferai? quels instruments utiliser ? quels implants privilégier et pourquoi? etc ... Google ne va pas répondre à ces questions.
Or en informatique je suis exactement comme ce patient. J'ai un problème. Je ne connais aucun outil. Tout comme celui qui cherche à soigner son acné par un remède et qui croit qu'il est tombé sur le forum idéal, moi aussi je cherche des gens qui ont eu le même problème que moi ... j'analyse leurs questions ... je compare avec mon problème ... je copie les réponses données ... ça marche je garde ... ça marche pas je continue ma route. Quand ça marche et que j'ai compris, je garde l'info dans un fichier pour une utilisation ultérieure. Mais tout ça alors que je connais aucun outil. Comment veux-tu que j'élabore un plan si je ne connais pas les outils à utiliser?
Je vais te surprendre : le fonction Trim ... avant toi, je ne savais même pas qu'elle existait.
Pour revenir au problème de date, je me rends compte aujourd'hui que mon calcul est en effet mauvais. Dans le tableau final, j'obtiens :
en colonne A la date en format jour
en colonne B la date en format 14/12/2010
je me suis dit que si je mets une fonction:
si A: mardi et colonne chirurgien: mon nom donc colonne X : 10 heures
si A: mercredi et colonne chirurgien: mon nom donc colonne X : 6 heures
si A: samedi ou dimanche ou jour férié pour tout le monde colonne X : 0
quand je mets la condition
If Range ('"A" & i)="Lundi" ... ce n'est pas reconnu.
Car en effet "Lundi" n'existe pas !
Je t'envoie un fichier.
J'ai mis un peu de temps à répondre, je suis sorti du bloc à 23H30! J'ai lu ton message. Je vais l'étudier demain
Merci pour tout.
re hello
J'ai relu tes explications. Dire que j'ai tout compris serait un peu vaniteux de ma part. Je re re lis demain.
J'ai compris que ce ne sera pas saccadé comme mon travail et il y aura beaucoup de chemins croisés et des résultats imbriqués.
Bien sur ma façon de faire avec les dates sera archaïque. Pourras-tu alors intégrer la condition du Temps Offert (TOffert) ? En me donnant une liste temporaire de chirurgiens type ChirurgienA, ChirurgienB, ChirurgienC ... etc une vingtaine avec du TOffert type 4 heures, 6 heures, 7,5 heures, 8 heures, 10 heures ...
Un exemple pour 2 chirurgiens suffira :
ChirurgienA : lundi 10 heures et mardi 8 heures
et ChirurgienB : mardi 7,5 heures et mercredi 6 heures
je pourrai m'adapter ensuite.
Merci.
Bonne nuit
Bonsoir,
Un apprentissage, et l'acquisition de connaissances demande un certain temps... ! Pour utiliser Excel et/ou VBA de façon efficace il ne faut certes pas 13 ans mais cela relève d'un apprentissage progressif permettant d'accroître la capacité que l'on a à utiliser ces outils. Et cette capacité s'accroît au fil des utilisations... Pour faciliter cet accroissement il est judicieux d'utiliser les difficultés rencontrées pour enrichir les connaissances générales dont on dispose.
Dans ton cas particulier de date, ce qu'il faut en tirer c'est la nécessité de distinguer clairement la valeur contenue dans une cellule de celle affichée. L'affichage dépend du format de cellule. Le format de cellule n'affecte pas la valeur contenue dans la cellule.
Si tu as la date du 02/01/2017, que tu l'affiches sous cette forme ou sous la forme 'lundi', tu auras toujours la même valeur date dans la cellule, et il est inutile d'y cherche le texte 'lundi' car ce texte ne constitue pas la valeur de la cellule.
Mais tu peux au moyen d'une fonction y chercher si c'est un lundi.
=SI(JOURSEM(A1)=2;"OK";"Erreur") te renverra 'OK' si la date en A1 est un lundi.
JOURSEM renvoie un numéro dans une série 1 à 7 pour les jours de la semaine du dimanche au samedi.
Et si tu as des indications à renvoyer variant selon le jour de la semaine, tu peux par exemple utiliser la fonction CHOISIR.
=CHOISIR(JOURSEM(A1);"indic.siDI";"indic.siLU";"indic.siMA";"indic.siME";indic.siJE;"indic.siVE";"indic.siSA")
La valeur renvoyée par JOURSEM est utilisée comme index par CHOISIR, les réponses fournies par la fonction selon l'index sont listées dans les arguments suivants à partir du 2e.
Pour ma démonstration d'extraction, je m'en tiens au problème initial, afin de ne pas tout mélanger.
Je conçois tout à fait que te lançant dans l'analyse du problème, tu ne le traduises pas spontanément de la même façon, en actions à réaliser qui se trouvent être réalisables en utilisant VBA.
Cependant la traduction en actions type : je parcours les lignes, je repère celles qui m'intéressent, j'y prélève des données, j'organise ces données dans un tableau que je veux obtenir en résultat, est possible indépendamment de toute connaissance de VBA ! On se posera ensuite la question de comment réaliser telle ou telle action. Ce que je veux induire, c'est d'abord qu'il n'y a pas lieu de se laisser influencer par la pratique que tu peux avoir d'Excel. Utilisant VBA, c'est autant que possible pour faire autrement que manuellement dans le tableur. Il faut donc viser une solution, la plus directe indépendamment de toute technique (chaque question en son temps). Ensuite, on peut rechercher la façon de faire en VBA (là j'ai pris un peu un raccourci en formulant d'une façon conforme aux possibilités offertes par VBA...). Et on ne se lance dans le codage du programme que lorsqu'on a tout analysé et que l'on sait comment on veut atteindre l'objectif de la façon la plus simple. Si on se met à coder dès qu'on a une idée, on s'en remet au hasard car rien n'indique qu'on part dans la bonne direction tant que l'on n'est pas arrivé au bout de la réflexion conceptuelle.
Il semble que tes investigations sur les problèmes de dates sont liés à des éléments que tu voudrais introduire dans ton tableau. Si c'est le cas, il aurait fallu les incorporer à la définition du problème posé au départ. Et leur leur aurait apporter une solution dans le même mouvement !
Comme je l'ai dit, je conserve le problème tel que posé au départ. Cela permettra parvenu au terme de voir comment on peut apporter des modifications qui n'était pas prévues au départ. Il faut être conscient que ce qui n'est pas prévu au départ peut obliger à tout refaire si l'on veut conserver la même efficacité. On pourra voir aussi que la programmation modulaire que j'ai évoquée à la fin de mon dernier post est un élément propre à faciliter les modifications d'un programme...
Cordialement.
Ton problème de temps offert, est un élément à la fois nouveau (que je laisse donc de côté pour l'instant) et extérieur aux éléments du problème envisagé jusqu'ici. Ce qui implique que pour inclure un tel élément, il faudra puiser à une source externe à la source à l'origine du problème en cours (feuille texte).
Tu peux donc d'ores et déjà constituer cette source externe de façon utilisable, soit si j'ai bien compris un tableau chirurgiens x jours de la semaine, dans lequel consigner les temps offerts en prendre en compte, par chirurgien et jour.
Etant encore debout, je vais avancer sur l'étape suivante consistant en l'analyse des données à extraire et des conditions dans lesquelles peut s'opérer cette extraction. En commençant par la date, ce qui recoupera des questions déjà discutées...
Recueil des données : la date
La date figure de loin en loin dans une ligne de texte, chaque fois que l'on rencontre l'une de ces lignes date, elle comporte une date qui se substitue à la précédente pour dater les interventions.
En parcourant les lignes de texte, il convient donc d'abord d'identifier une telle ligne date.
Une fois la ligne identifiée, il faudra en extraire la date et la stocker dans une variable pour pouvoir l'utiliser en inscrivant une intervention.
La question de la détection pose quelque difficulté ! On dispose en VBA d'une fonction IsDate qui permet d'identifier si un littéral date peut être converti en date.
Cependant la date apparaît dans la ligne de texte sous la forme Jour de la semaine suivi de la date au format jj/mm/aaaa, les deux éléments étant séparés par une espace. Un tel texte ne sera pas reconnu comme date...
Il faut donc sortir le 2e élément de la date du texte pour vérifier qu'il s'agit d'une date. Pour alléger la procédure principale, ainsi qu'on l'a déjà évoqué, on peut externaliser cette manipulation et établir une fonction qui l'opèrera et renverra True si l'on a affaire à une date. Et l'on utilisera cette fonction comme l'on aurait utilisé IsDate...
L'on fournit à la fonction le texte de la ligne testée, et elle renvoie une valeur booléenne permettant d'établir s'il s'agit d'une date.
Function EstDateInterv(dInterv As String) As Boolean
Dim d
d = Split(Trim(dInterv))
EstDateInterv = IsDate(d(1))
End FunctionComme on le voit, on établit facilement une telle fonction : on splitte le texte transmis dans une variable et on en teste le 2e élément avec IsDate (les indices de tableau débutant à 0 par défaut, le 2e élément est d'indice 1).
Une fois la ligne identifiée comme ligne date, il convient de récupérer cette date pour la stocker afin de l'utiliser par la suite.
On opèrera cette opération de la même façon en établissant une fonction qui renverra la date...
Function DateInterv(dInterv As String)
Dim d
d = Split(Trim(dInterv))
DateInterv = CLng(DateValue(d(1)))
End FunctionOn procède de la même façon que précédemment, mais on renvoie la date convertie avec DateValue...
Enfin c'est ce qu'on ferait spontanément !
Ce qui paraît illogique, d'autant qui si l'on opère des tests intermédiaires pour vérifier la date, avant affectation au tableau et après affectation à un élément du tableau, la date renvoyée est bien la bonne ! C'est donc qu'elle est encore l'objet d'une nouvelle conversion par VBA lors de l'affectation à la feuille Excel.
Cela peut s'expliquer dans la mesure où la fonction DateValue renvoie une valeur de type Date, valeur qui exprimée littéralement donne lieu à conversion automatique.
Au passage, cela permet de constater que la fonction VBA DateValue ne fonctionne pas identiquement à la fonction Excel DATEVAL dont elle paraîtrait logiquement parente : DATEVAL renvoie elle une valeur numérique, valeur sous laquelle est stockée une date dans Excel.
On est donc amené à rectifier la fonction établie de façon qu'elle renvoie la date issue de la conversion par DateValue sous forme d'un entier Long en la convertissant en Long avec la fonction CLng. De cette façon elle ne sera plus l'objet d'une nouvelle conversion indésirable.
On sait que dans ce cas il conviendra de définir un format de cellule date lors de l'affectation, mais comme on voulait l'afficher en faisant apparaître le jour de la semaine, il fallait de toute façon redéfinir le format de cellule, cela n'implique donc pas d'autre modification.
En procédant de cette façon dans l'exposé, je fais l'impasse sur le débogage...
Sauf dans le cas de quelques lignes de code d'instructions simples rendant difficile de faire quelque erreur, il est bien rare de ne pas avoir une virgule ou un point mal placé, ou en trop, ou manquant, ou quelque faute de frappe, ou un nom de variable estropié, etc.
Et si aucune erreur n'apparaît il convient de vérifier de toute façon que le résultat obtenu est conforme à ce qu'on attend. Toutes les erreurs ne se manifestent pas en erreurs d'exécution ou erreurs de compilation...
Si aucun débogage à faire et aucune autre erreur constatée, c'est qu'on a eu de la chance ou qu'on n'a pas encore testé le cas suceptible de faire apparaître une erreur !
Donc si tu écris une macro, et que dès le premier test tu obtiens une erreur... dis-toi que rien de plus normal ! Avoir des erreurs n'est pas l'apanage des débutants... c'est en fait plutôt la difficulté à les voir et les rectifier rapidement... La plupart, telles celles que j'ai mentionnées se rectifient facilement, d'autres sont plus difficiles à déceler, mais je ne m'étends pas plus là-dessus car cela pourrait faire l'objet de plusieurs sujets...
Suite à venir...