Discussion :

[L'AMI Yves]

Encore une fois bonjour à tous.

Je suis toujours dans mon application de gestion de rendez-vous. Elle comporte deux tables : une tables des personnes, qui contient des adresses et des temps de trajet, et une table des rendez-vous, qui fait référence à des personnes et qui contient des dates et heures de rendez-vous. Théoriquement, avec ces informations, il est possible de décider à quelle heure il faut déclencher une alarme pour se rendre au rendez-vous. Pour cela, il faut être capable d'additionner - ou plutôt de soustraire - le temps de trajet à l'heure du rendez-vous.

Je n'ai trouvé chez Google qu'un vague document sur la gestion des dates en VBA. Je me suis déjà confronté à ce genre de questions en PHP/MySQL, en Python/SQLite, je me souviens que c'est relativement abscons.
Quelqu'un peut-il me conseiller de la documentation pour VBA/Access, SVP.

D('avance, merci.

AMIcalement.

[Philippe Tulliez]

Bonjour,
Un petit tour vers la FAQ - VBA→Manipulation des données→Dates et Heures

[L'AMI Yves]

Dans mon formulaire, j'ai trois contrôles qui contiennent une heure. Ils sont tous formatés avec "Heure, abrégé". L'un contient "Maintenant()", un autre est rempli par l'utilisateur, et le troisième provient d'une table par l'intermédiaire d'une liste déroulante.

Avec les deux premiers, je fais une comparaison toute bête :"if un > deux", et ça a l'air de marcher. Mais j'essaie de calculer "deux" en mettant dans la source de contrôle du formulaire la formule "=[un] - [trois]" et le contrôle affiche toujours "#Type !" (il faut préciser aussi que le contrôle "trois" affiche un temps en "hh:mn:ss", je ne sais pas si ça a à voir)

Il y a bien sûr une solution en mettant une procédure, ce que je ferai en cas de besoin, mais j'aimerais comprendre...

[Philippe Tulliez]

Bonjour,
En utilisant le générateur d'expression dans des TextBox indépendants du formulaire ou d'une requête c'est relativement simple

Voici un exemple vite fait où j'ai créé deux tables nommées t_Planning et t_Task (voir plus bas l'illustration des relations, champs, etc.)

Illustration du formulaire
Sa source est la table t_planning et il y a deux TextBox indépendants nommés txtDureeTask et txtFinTask qui sont alimentées par le générateur d'expression (voir la formule dans les zones en bleu)
Lorsque l'on sélectionne dans la liste déroulante l'un des éléments, automatiquement les calculs sont modifiés



Illustration 2



[EDIT]
Pour en savoir plus sur les Fonctions de domaine vs sous-requêtes

[L'AMI Yves]

Merci Philippe.

Le lien conduit à un document qui me dépasse encore trop.

Par contre, ton exemple ressemble trait pour trait à mon cas. Enfin , on va voir : j'ai un contrôle "Zone de liste déroulante" qui me permet de choisir une personne. Cette liste a 3 colonnes : le numéro de la personne dans sa table, la concaténation de ses prénom et nom, et le temps de trajet pour s'y rendre. La première et la dernière ont une largeur nulle. Les contrôles "NumP" et "Temps-Trajet" sont "liés" à ces colonnes (par le signe "=" vers la colonne dans la "Source Control").

Le formulaire a aussi un contrôle "Heure-RV" formaté en "Heure abrégé", et le contrôle "Heure-Alarme" a pour source la formule "=[Heure-RV]-[Temps-Trajet]". Il est aussi formaté en "Heure, abrégé". Quand le formulaire est ouvert, vide, il affiche "#Type !"

Le contrôle "Temps-Trajet" sera invisible en mode "opérationnel", mais pour le moment, je le vois, et, bien qu'il soit formaté en "Heure, abrégé", il s'affiche au format "hh:mn:ss", ce qui me paraît suspect. Et, quand je remplis le contrôle "Heure-RV", l'"Heure-Alarme" reste avec son "#Type".

J'espère avoir été assez clair.

AMIcalement.

[tee_grandbois]

bonsoir,

Le contrôle "Temps-Trajet" sera invisible en mode "opérationnel", mais pour le moment, je le vois, et, bien qu'il soit formaté en "Heure, abrégé", il s'affiche au format "hh:mn:ss", ce qui me paraît suspect.

ce n'est pas formaté car un colonne de liste déroulante renvoie TOUJOURS du texte, quelque soit le type de données, et c'est le cas pour le temps de trajet, il faut donc passer par une conversion de données en ajoutant Cdate dans la source contrôle (voir la discussion précédente):

Code :

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

=CDate(Liste.[Column](2))

[L'AMI Yves]

Je m'incline avec toute la modestie d'un débutant : ÇA MARCHE !

Il reste cependant encore un truc qui coince : ce champ "Heure-Alarme" est un champ de la table sous-jacente de ce formulaire, et, dans le fonctionnement de ce formulaire, sa valeur est calculée, comme o, vient de réussir à le faire. Le formulaire est ouvert en "datamode:=acFormAdd", pour créer un nouvel enregistrement dans cette table. Sur le bouton "OK", j'ai mis la macro "Sauvegarder enregistrement", mais quand je le fais, j'ai un message "Vous devez entrer une valeur dans le champ "Rendez-vous.Heure-alarme" : le formulaire ne s'aperçoit pas que le champ est rempli automatiquement.

Je suppose que cela se résout aussi simplement que tous mes autres problèmes....

AMIcalement.

[L'AMI Yves]

RE-bonjour.

En cherchant à résoudre par mes propres (et pauvres) moyens à résoudre ce problème de message d'erreur, Google me parle de deux propriétés qui pourraient m'y aider : "Obligatoire" et "Valeur par défaut". Or ce champ ne possède aucune de ces propriétés !

D'ailleurs, aucun champ de mon formulaire ne les possède.Est-ce une question de version ?

En tout cas, je n'ai pas avancé !

AMIcalement.

[L'AMI Yves]

Je continue mes essais. En fait, cette propriété "Obligatoire" s'applique à la colonne de la table. Qu'à cela ne tienne : je le mets à "Non" dans la table, et je vais dans mon formulaire : tout marche à merveille , le calcul de l'heure-alarme se fait bien et je peux sauvegarder mon enregistrement. Je vais vérifier ma table : "Heure-alarme" est vide !

Je suis maudit !

Venez vite me sauver.

AMIcalement.

[tee_grandbois]

Venez vite me sauver.

si tu as le formulaire et la table en question disponibles dans une base compactée et zippée, pourquoi pas ?

[L'AMI Yves]

Merci !

Envoi.zip

AMIcalement.

[tee_grandbois]

comment veux-tu saisir un champ dont la source contrôle est un champ calculé ?



en saisie de donnée, la propriété "source contrôle" doit contenir les champs de la table et pas autre chose

[L'AMI Yves]

Je te remercie de ta compréhension, mais, en vérité, je ne comprends pas. Est-ce que toi, tu comprends la logique de ce que je veux faire : ce champ est destiné à la table des rendez-vous, et c'est la combinaison d'un champ de cette table (Heure-RV) et d'un champ de la table des personnes (Temps-trajet). L'utilisateur pourrait faire ce calcul lui-même, alors pourquoi l'interdire à l'ordinateur ? Pourquoi n'y a-t-il pas le même problème avec Jour-RV, NumP et Temps-Trajet ? NumP est aussi un champ destiné à l'enregistrement. Est-ce que c'est par ce que la valeur est calculée ? Quelle serait la raison de cette limite ?

AMIcalement.

[tee_grandbois]

Pourquoi n'y a-t-il pas le même problème avec Jour-RV, NumP et Temps-Trajet ? NumP est aussi un champ destiné à l'enregistrement.

c'est exact c'est en relisant tes posts que j'ai compris que le champ n'était pas saisi:

c'est la combinaison d'un champ de cette table (Heure-RV) et d'un champ de la table des personnes (Temps-trajet).

l'ordre de tabulation est important dans une saisie et il ne faut pas non plus que les champs calculés soient activés et qu'ils aient donc le focus.
Et, personnellement, je mettrais la mise à jour de Heure-alarme sur clic du bouton OK pour ne plus avoir le libellé #type! dans la zone de texte quand c'est vide, idem pour le jour-RV après mise à jour de la date de RDV.
Je joins la base avec seulement le formulaire Rendez-Vous avec les corrections: RDV.zip

j'ai trouvé ça aussi dans le formulaire Post-it:



il me semblait avoir donné la solution du problème du coup, je me demande pourquoi on te donne des solutions... j'aime à penser que c'est une ancienne version

[L'AMI Yves]

Je te remercie, je mets tout ça en place.

Pour la survivance d'une ancienne erreur, en effet, c'est une erreur. J'invoque l'excuse de mes difficultés et d'un sens de l'organisation pas trop performant, et la coexistence de plusieurs versions, et de plusieurs filières de corrections. Je regrette que cela te rende acerbe. Je fais de mon mieux.

Encore merci, et sans doute à bientôt.

AMIcalement.

[tee_grandbois]

bonjour,

Je regrette que cela te rende acerbe. Je fais de mon mieux

pas du tout, cela m'a rendu plutôt perplexe, mais j'ai quand même évoqué l'éventualité de l'usage d'une ancienne version ... d'ailleurs à ce propos pour la base à poster, j'avais demandé juste le formulaire et la table.

L'essentiel est que tu comprennes que pour saisir des données dans les champs d'une table via un formulaire, il faut que la donnée soit présente (propriété Source contrôle = nom du champ de la table), si un calcul met à jour un champ de la table il faut le faire une fois que tous les champs (dans un formulaire, on parle de contrôles) issus du calcul sont renseignés: soit après mise à jour des contrôles, soit après mise à jour du formulaire ou sur clic d'un bouton.
bonne continuation

[L'AMI Yves]

Merci encore.

Ta remarque sur la mise à jour des champs vaut même si le formulaire est ouvert en "datamode:=acFormAdd" ?

AMIcalement.

[tee_grandbois]

pas de quoi, mais ta question prouve que tu n'as pas compris mon explication ... puisque tu as développé dans d'autres langages explique-moi comment tu peux modifier la colonne d'une table depuis un formulaire (IHM, écran ...) si cette colonne n'est pas spécifiée (sans alias ou autre subterfuge) ?
Après, oui, il y a la possibilité de faire un ajout ou une mise à jour par une requête à partir de champs indépendants (sans source contrôle ou avec des champs calculés) mais la destination reste la table et ses colonnes (mais ce n'est pas la méthode la plus simple)

mais je répond quand même: en modification comme en ajout le principe est le même