Discussion :

[tee_grandbois]

car "On error resume next" me semble signifier que toutes les erreurs sont gérées, non ?

si on veut : cette instruction, en cas d'erreur, ignore le message et continue le code (sauf si tu a coché "Arrêt sur toutes les erreurs") donc tu as vraiment un problème ...

Ton message d'erreur, tu l'as trouvé dans quelle fenêtre de VBA ?

dans la fenêtre VBA principale, si on appuie sur le bouton "Débogage", Access se positionne sur la ligne en erreur qui apparait surligné en jaune, bref le processus normal ...

[L'AMI Yves]

Ah ! Je suis allé un peu plus loin : j'ai ajouté l'instruction "On error resume next", et là, en effet, il continue son exécution.

Voici le bout de code où il doit y avoir une erreur :

Code VBA :

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

1
2
3
4
5
6
7
 
        For Each ctr In Me.Controls ' RAZ de tous les contrôles
          If TypeOf ctr Is TextBox Then
              Debug.Print ctr.Name & " " & ctr.Value
              ctr.Value = Null
          End If
        Next

Cette boucle va maintenant à son terme, mais certains textbox du formulaire ne sont pas "RAZ", et il semblerait que ce soient ceux qui ne contiennent qu'un seul mot (ou chiffre).

Mais je ne sais pas quelle est l'erreur...

AMIcalement.

[L'AMI Yves]

Maintenant je sais : erreur 2448 "impossible d'attribuer une valeur à cet objet". Mais pourquoi cela se produit-il sur certaines textbox et pas sur d'autres ?

Et cela me montre que je suis parti sur une fausse piste : si l'on affiche dans un formulaire les données d'un enregistrement d'une table, tout se passe comme si toute modification d'une champ du formulaire est instantanément reportée dans la table. 1) Est-ce exact ? et 2) Est-il possible d'attendre une confirmation de l'utilisateur, par exemple par l'appui sur une touche "OK" ?

AMIcalement.

[deedolith]

Ah ! Je suis allé un peu plus loin : j'ai ajouté l'instruction "On error resume next"

L'instruction On Error Resume Next n'a pas vocation à être utilisée à la légère.
ce n'est pas une instruction "de confort".

Tu dois être pleinement conscient de ses conséquences:
Ignorer une erreur ne signifie pas la prendre en charge, au mieux il ne se passe rien, au pire tu as introduit un bug particulièrement difficile à détecter puisqu'il passe sous silence.

Poses toi les bonnes questions:
L'erreur a-t-elle un impact ?
Est-il pertinent de la discriminer ? (via son numéro).
Peut elle être prise en charge dans la fonction courante ?
Peut elle être prise en charge dans la fonction appelante ? (Il convient alors de l'escalader).
Est-il prudent de l'ignorer ?

[L'AMI Yves]

Merci, Deedolith, mais apparemment, tu as raté mon dernier post : en effet, "On error resume next" m'a permis de voir qu'il y avait bien une erreur quelque part, puisque, dans ce cas, la boucle allait à son terme. Mais ça ne m'apprenait rien sur l'erreur. A l'étape suivante, j'ai fait "On error goto Err" et là, j'ai mis un message, ce qui m'a appris que l'erreur portait le numéro 2448, comme dit dans mon dernier post.

Mais tu sais peut-être répondre aux deux questions qui suivent...

AMIcalement.

[tee_grandbois]

erreur 2448 "impossible d'attribuer une valeur à cet objet". Mais pourquoi cela se produit-il sur certaines textbox et pas sur d'autres?

probablement sur la textbox qui contient la clé primaire et celles dont la valeur nulle est interdite ...
et à quoi te sert cette boucle, à part ça ?

[L'AMI Yves]

J'ai peur de me faire encore remonter les bretelles... Mon formulaire est ouvert depuis un autre, et il affiche un enregistrement d'une table. Le besoin de l'utilisateur peut être tout simplement de consulter cet enregistrement : dans ce cas, il n'y a rien à faire, et les paramètres du formulaire ne permettent pas de faire de modifications.

Mais il peut avoir d'autres intensions, et j'ai parlé par ici l'autre jour de mes cinq boutons : "Nouveau", "Modifier", "Supprimer", "Dupliquer" et "Annuler". A l'ouverture du formulaire les quatre premiers sont rouge, et le dernier vert. Aucune modification n'est possible sur le formulaire. L'utilisateur peut appuyer sur l'un des boutons rouge, qui devient vert et le formulaire doit autoriser l'utilisateur à préparer cette action en agissant sur les contenus des contrôles. Puis l'action sera exécutée si l'utilisateur clique sur ce bouton vert, ou tout sera annulé s'il clique sur "Annuler".

Au vu de tout ce que j'ai pu lire sur le fonctionnement d'Access, ce que je veux faire ne me semble pas courant. Pourtant il ne me semble pas aberrant de désirer fonctionner comme cela : on demande à l'utilisateur d'indiquer son intention, on le laisse préparer cette action, et on attend qu'il la valide pour l'exécuter.

Reste à savoir si Access le permet. C'est l'objet de ce post (plus un peu d'aide pour y parvenir...).

La boucle en question était censée préparer un enregistrement vierge pour "Nouveau".

Merci d'avance.

AMIcalement.

[tee_grandbois]

La boucle en question était censée préparer un enregistrement vierge pour "Nouveau".

si tu relis ce post (le #31) je t'ai déjà donné la solution:

Code :

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

1
2
3
4
' ...
DoCmd.GoToRecord acDataForm, Me.Name, acNewRec
' ...
End Sub

la commande GotoRecord avec option acNewRec affiche le formulaire avec un nouvel enregistrement donc, VIDE, du coup il est inutile de réinventer le fil à couper le beurre, car il existe déjà ...

[L'AMI Yves]

Oui, c'est vrai que je me perds un peu dans tout ça.

Mais ta solution attend-elle la validation, ou bien les champs vont-ils se remplir au fur et à mesure des saisies de l'utilisateur ?

Et peux-tu me donner un conseil pour "Dupliquer" : il va s'agir de créer un nouvel enregistrement en "pré-remplissant" ses champs avec les données du formulaire en cours ?

AMIcalement.

[tee_grandbois]

Mais ta solution attend-elle la validation, ou bien les champs vont-ils se remplir au fur et à mesure des saisies de l'utilisateur ?

sais-tu créer un formulaire de saisie qui se remplit tout seul ???
ma solution n'est pas pire que la tienne qui part d'un enregistrement existant pour l'effacer:

La boucle en question était censée préparer un enregistrement vierge pour "Nouveau".

en tout cas ma solution est ce qu'il y a de plus standard.

Pour ce qui est de dupliquer un enregistrement, tu peux lancer un SQL d'ajout ...
pour ce qui est de se positionner sur l'enregistrement créé, cela parait facile en se plaçant sur le dernier (Max du numéro auto), mais il faut s'assurer que 2 utilisateurs ne font pas une création au même moment et pouvoir reconnaitre l'enregistrement que chacun a créé ...

[L'AMI Yves]

Merci, tee_grandbois, d'être toujours présent.

J'ai du mal à me glisser dans les habits d'un développeur Access...!

Est-ce pour cela que j'ai l'impression de n'avoir pas reçu de réponse à ma grande question : le formulaire Access est-il adapté à ma "philosophie" de laisser l'utilisateur faire ses petites bidouilles, et de ne valider les saisies qu'ensuite, en cliquant sur un bouton de validation de l'ensemble des saisies ?

Pour dupliquer un enregistrement (le cas que j'imagine, c'est celui ou l'on veut modifier juste une ou deux informations) tu me suggères une instruction SQL : elle serait alors générée à partir d'une recopie des tous les champs (sauf le numéro, bien sûr). Mais s'il est possible de fonctionner selon ma "philosophie", il me semble qu'il serait plus logique de mémoriser les valeurs des contrôles d'origine, puis se placer sur le dernier enregistrement et les recopier, de façon à laisser l'utilisateur faire ses modifs puis valider. Mais est-ce conforme à la "philosophie" d'Access ?

AMIcalement.

[tee_grandbois]

bonsoir,

Mais s'il est possible de fonctionner selon ma "philosophie", il me semble qu'il serait plus logique de mémoriser les valeurs des contrôles d'origine, puis se placer sur le dernier enregistrement et les recopier, de façon à laisser l'utilisateur faire ses modifs puis valider. Mais est-ce conforme à la "philosophie" d'Access ?

je me répète car tu ne sembles pas comprendre les mots que j'emploie: c'est bien ce que je te propose de faire avec une requête d'ajout sur un bouton dupliquer, puis ensuite on se positionne sur cet enregistrement ...

[L'AMI Yves]

Encore une fois, merci de ta patience... mais je crois que c'est toi qui ne comprends pas mon problème, peut-être par ce que ça n'en est pas un : je désire que la table ne soit modifiée que sur clic sur un bouton. Quand j'ai fait mon premier essai d'effacer le contenu des contrôles, ça n'a pas très bien marché, sans doute par ce que le caractère "espace" (ou vide, je ne me souviens pas) ne correspondait pas au format du contrôle, mais pour les champs où ça marchait, j'ai retrouvé ces "vides" dans la table : je voudrais comprendre comment éviter cela.

AMIcalement.

[tee_grandbois]

mais je crois que c'est toi qui ne comprends pas mon problème, peut-être par ce que ça n'en est pas un : je désire que la table ne soit modifiée que sur clic sur un bouton.

oui, un bouton dupliquer, par exemple

[tee_grandbois]

mais pour les champs où ça marchait, j'ai retrouvé ces "vides" dans la table : je voudrais comprendre comment éviter cela.

tu n'as pas l'air de comprendre qu'un formulaire affiche un (ou plusieurs) enregistrement(s) de la table, si tu effaces ce qu'il y a dans les contrôles (Textbox) de ce formulaire cela efface immédiatement les données de l'enregistrement concerné

[L'AMI Yves]

C'est en effet une chose que j'ai mis longtemps à comprendre, mais ceux qui savent ça depuis longtemps n'ont pas compris ce que j'explique depuis le début. Ceci étant, je m'explique mal la nécessité de "Me.Requery" qu'il m' fallu mettre je ne sais plis où il y a quelque temps...

Quoi qu'il en soit, si je veux continuer dans ma voie, il va falloir faire les pieds au mur, j'ai bien peur...

[tee_grandbois]

Ceci étant, je m'explique mal la nécessité de "Me.Requery" qu'il m' fallu mettre je ne sais plis où il y a quelque temps...

comment veux-tu qu'on te suive si tu mets constamment du "hors-propos" à chaque post ?
quel rapport avec la création d'un nouvel enregistrement issu d'un existant ?

[star]

Bonjour,
Je pense qu'il faudrait clôturer ce fil et en ouvrir un nouveau qui se concentrerait sur la problématique.
On diverge par rapport au sujet initial ce qui prête à confusion.
Bon DEV à tous
.

[L'AMI Yves]

Bonjour à tous.

J'ai été bien sage depuis quelques temps... et j'ai bien travaillé : mon application est presque prête : toute la logique est en place, il n'y a plus que du cosmétique à faire. En dernier, j'ai voulu appliquer la solution proposée par Ric500 pour ne plus avoir à l'écran que mes formulaires. Mais ça m'a semblé une usine à gaz ! il y a des qantités de trucs dont je n'ai pas besoin (je retiens juste les formulaires rond, ou de forme bizarre...) J'ai donc essayé d'en tirer juste ce dont j'avais besoin, dans la partie "Form_FrmSystray.ShowAccesWindow" et "Form_FrmSystray.HideAccesWindow".

Pour changer, je n'ai pas dû faire exactement ce qu'il fallait, et maintenant, la situation est la suivante : quand j'ouvre ma base de données, voici ce qui apparait :
- mon formulaire, qui fonctionne,
- une petite fenêtre portant comme titre le nom de mon application et comme barre de menu "Fichier" qui a trois sous-menus : "Imprimer", "Options de confidentialité", et "Quitter".

Et si je double-clique sur mon ".accdr" en maintenant la touche "Shift" enfoncée, il se passe exactement la même chose.

Merci a qui voudra bien me proposer des idées pour récupérer ce qui peut l'être... J'ai des sauvegardes, mais un peu anciennes...;o(

AMIcalement.

[L'AMI Yves]

Je me réponds à moi-même : ouvrir ma base en maintenant "Shift" enfoncé ne marchait pas, mais en lançant d'abord Access, puis en ouvrant la base, j'ai repris la main.

Donc tout baigne.

Bonne journée à tous dans ce monde si serein...

AMicalement.