Discussion :

[Access_ible]

Bonjour.

J'ai découvert récemment cette fonction qui a changé ma façon de travailler sous Access :

http://www.developpez.net/forums/d74...e-formulaires/

Un très grand merci et bravo à JBO !

Je m'en suis servi à plusieurs reprises en créant une requête avec l'assistant graphique création de requêtes d'Access.

Ma requête comporte un table, 4 champs et demande une opération de regroupement.

Un seul critère de recherche est indiqué, il a comme origine le contrôle d'un formulaire.

Ça marche !

Mais j'ai déplacé le formulaire pour en faire un sous formulaire…

J'ai essayé tout ce que j'ai pu trouver concernant l'orthographe du code faisant référence aux sous formulaires : [] ! . Forms!Form Control. .Value, un maximum de combinaisons…

Le résultat est toujours le même : soit il m'affiche une message box qui semble indiquer qu'il ne trouve pas le contrôle en question et me demande de rentrer la valeur manuellement, soit le résultat est celui que j'ai prévu en cas d'un recordset vide (.EOF)…

Il se trouve que je débute en recordset et que je me suis juste contenté de recopier le code de DAO_GenericOpenRecordset.

Je soupçonne quand même que quand j'ai une messagebox, ce n'est pas forcément qu'il ne trouve pas le contrôle…

Je penses avoir compris que dans le code, si Eval() ne sais pas "évaluer" quelque chose, il envoi aussi une message box pour que l'utilisateur complète la chose.

Je me demande si je ne vais pas faire une réparation au fil de fer en faisant en sorte que la message box reçoive le contrôle que je vise…

Mais il doit bien y avoir une méthode pour que DAO_GenericOpenRecordset sache lire la requête dans son entier, avec prise en compte du sous-formulaire.

Je pense avoir fait le tour des erreurs de mon fait (renommer les formulaires, les champs, rcréer la requête...)

Mais il y a peut-être des subtilités des fonctions DAO_GenericOpenRecordset, Eval(), Recordset qui m'échappent, ou peut être des limites d'utilisations.

Code :

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

1
2
3
4
SELECT First(TB0110_UTLSTR.UTLSTR_LGN) AS PremierDeUTLSTR_LGN, TB0110_UTLSTR.UTLSTR_MDP, TB0110_UTLSTR.UTLSTR_NM, TB0110_UTLSTR.UTLSTR_PRNM
FROM TB0110_UTLSTR
GROUP BY TB0110_UTLSTR.UTLSTR_MDP, TB0110_UTLSTR.UTLSTR_NM, TB0110_UTLSTR.UTLSTR_PRNM
HAVING (((First(TB0110_UTLSTR.UTLSTR_LGN))=[Formulaires]![FO2100_PST]![FO2200_PASS]![LoginMaster]));

Je me dit que le problème doit se situer ici :

Code :

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

=[Formulaires]![FO2100_PST]![FO2200_PASS]![LoginMaster]));

Mais je ne vois pas comment l'écrire d'une manière que je n'aurais pas encore essayé, sans succès…

Comment (si c'est possible) écrire cette partie pour que DAO_GenericOpenRecordset fasse le boulot ?

D'avance merci.

[loufab]

Bonjour,

Je te propose cette solution parmi d'autre :

Dans un module standard :

Code :

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

1
2
3
public function getValueControl() as variant
getValueControl = Forms.NomFormulaire.NomSousFormulaire.Form.NomMonControle
end function

Et dans ta requète :

Code :

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

1
2
3
4
 
SELECT ...
..
HAVING (((First(TB0110_UTLSTR.UTLSTR_LGN))=getValueControl()));

C'est l'un des contournements possibles. Tu peux enrichir la fonction vba avec des vérifications ou des traitements divers.

Edit :
En relisant ton codes on voit une erreur dans l'appel :

Code :

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

=[Formulaires]![FO2100_PST]![FO2200_PASS]![LoginMaster]));

Alors qu'il faut écrire :

Code :

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

=[Formulaires].[FO2100_PST].Form.[FO2200_PASS].[LoginMaster]));

Si tu ne sais pas faire les appels consultes mon tuto :
http://loufab.developpez.com/tutorie...pelformulaire/
et imprime le pense-bête
http://loufab.developpez.com/

Cordialement,

Cordialement,

[Access_ible]

Bonsoir.

Merci pour cette réponse.

J'ai essayé de saisir cela dans un module (c'est-à-dire dans un module à part, pas lié à un formulaire ou un état)

Code :

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

1
2
3
Public Function getValueControl() As Variant
getValueControl = FormsFO2100_PST.Form.FO2200_PASS.LoginMaster
End Function

J'ai remplacé la partie du texte SQL par l'appel de la fonction.

Erreur d'execution 424, objet requis, ligne "getValueControl = FormsFO2100_PST.Form.FO2200_PASS.LoginMaster" en jaune, en boucle (obligé de cliquer trois fois sur "fin" pour sortir)

J'ai déplacé Public Public Function getValueControl() dans le module du formulaire.

C'est pire, il affiche une message box avec une ligne pour faire une saisie, les boutons OK et annuler et c'est tout, pas la moindre info.

4 clics sur fin pour sortir…

Quand à l'erreur dans l'appel, elle n'est pas de mon fait.

Je me suis contenté de créer la requête avec l'assistant graphique Access, de basculer en mode SQL et de faire un copier/coller.

Ça marche tel quel, quand le contrôle qui sert de critère à la requête se trouve dans le formulaire et pas dans un sous formulaire.

Je ne suis même pas sur que "traduit" par DAO_GenericOpenRecordset, il faille écrire l'appel selon la bonne grammaire d'Access, car il me semble par exemple que DAO_GenericOpenRecordset recherche les différentes façons d'écrire Forms! En SQL

Extrait :

Code :

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

1
2
3
4
Each v In Array("[Forms]!", "[Formulaires]!", "Formulaires!")
                    If InStr(1, sExprColl, v) = 1 Then
                        sExpr = Replace(sExprColl, v, "Forms!")
                        Exit For

Il est donc possible qu'il ne sache pas quoi faire de "Forms."

Je suis de plus en plus convaincu que DAO_GenericOpenRecordset ne sait pas gérer les sous-formulaires comme argument et que donc, peu importe comment on le rédige, il ne sait pas "traduire".

Mais je n'ai aucun moyen de le vérifier…

J'ai lu votre documentation.

Un très grand merci pour les outils formidables que vous mettez gratuitement à disposition de la communauté.

J'ai retrouvé (malheureusement) les notions que vous indiquez dans votre précédent message.

Du coup je ne suis pas plus avancé…

J'ai réussi à faire ce que je voulais en modifiant le code de DAO_GenericOpenRecordset.

Quand il ne sait pas quoi faire d'une donné, il affiche une messagebox pour que l'utilisateur saisisse la valeur.

J'ai modifié le code pour que dans ce cas il aille directement chercher la valeur dans le contrôle du sous formulaire.

ça marche donc pour une requête avec un seul contrôle comme critère.

Mais si la requête utilise deux contrôles différents pour deux critères différents, ma bidouille pointe toujours le même contrôle.

Je ne sais vraiment pas quoi faire…

J'étais content d'avoir trouvé ça parce que ça me permettais de ne plus créer des sous formulaires juste pour une donnée et des tables temporaires…

Mais si ça ne marche pas pour les contrôles des sous-formulaires…

Je ne sais plus quoi faire…

Encore merci.

[loufab]

Bonjour,
VBA est une science exacte, il faut donc adapter le code fourni sans en oublier en route.

Relis-toi et compare caractère par caractère pour trouver l'origine de l'erreur.
Je me suis arrêté à ta retranscription erronée, je n'ai pas lu le reste.

Cordialement,

Ps : par acquis de conscience je voulu allez plus loin dans cette lecture, et je me suis définitivement arrêté sur cette phrase :

"Quand à l'erreur dans l'appel, elle n'est pas de mon fait."

[Access_ible]

Bonsoir.

Merci pour le suivi.

Bonjour,
VBA est une science exacte, il faut donc adapter le code fourni sans en oublier en route.

Relis-toi et compare caractère par caractère pour trouver l'origine de l'erreur.

Oups !

Effectivement, sur le code que j'ai joint, ce n'est pas bon, je ne sais pas ce qui c'est passé...

J'ai donc bien tout revérifié et ce coup-ci j'ai saisi ceci dans un module :

Code :

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

1
2
3
Public Function getValueControl() As Variant
getValueControl = Forms.FO2100_PST.FO2200_PASS.Form.LoginMaster
End Function

Je croise les doigts pour que la "panne" vienne en fait de cette erreur de saisie.

Et c'est gagné !

Mon erreur 424 s'est muée en "Erreur 2465, erreur définie par l'application ou par l'objet"

"getValueControl = Forms.FO2100_PST.FO2200_PASS.Form.LoginMaster" surligné en jaune

3 clics de plus sur "Fin" pour sortir.

Pas mieux…

[…]Ps : par acquis de conscience je voulu allez plus loin dans cette lecture, et je me suis définitivement arrêté sur cette phrase :

"Quand à l'erreur dans l'appel, elle n'est pas de mon fait."

Oulà ! Décidément, je les ai cumulés sur ce précédent post.

C'est vrai que, sorti de son contexte de cette manière, ça me fait passer pour présomptueux…

En fait, ce que voulais dire, c'était que :

Quand à l'erreur dans l'appel, elle n'est pas de mon fait :
- Je me suis contenté de créer la requête avec l'assistant graphique Access, de basculer en mode SQL et de faire un copier/coller.
- Ça marche tel quel, quand le contrôle qui sert de critère à la requête se trouve dans le formulaire et pas dans un sous-formulaire.

Voilà, c'est mieux comme ça.

Du coup, comme indiqué précédemment, je me dis (sans pouvoir m'en assurer seul, bien sur) que DAO_GenericOpenRecordset doit buter sur la lecture des sous-formulaires…

C'est dommage, car j'avais mis en œuvre le système d'onglets couleur de l'inestimable Philippe JOCHMANS (http://www.developpez.net/forums/d40...nglet-couleur/, un immense merci à lui aussi…)

Je pense que je vais finir par revenir à des onglets standard avec un rectangle de couleur en fond, au moins tout sera sur un même formulaire et je pourrais continuer à faire mes copier/coller depuis l'assistant Access…

Encore merci.

[loufab]

Bonjour,
Procédons par ordre pour tenter de cerner le problème.

Dans un premier temps, ouvre le formulaire comme si tu devais l'utiliser.

Va dans l'Editeur VBA, fenêtre d'exécution et tape :

Code :

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

? Forms.FO2100_PST.name

il devrait te renvoyer : FO2100_PST

Puis poursuis par :

Code :

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

? Forms.FO2100_PST.FO2200_PASS.name

il devrait te renvoyer : FO2200_PASS

puis :

Code :

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

? Forms.FO2100_PST.FO2200_PASS.Form.LoginMaster.name

il devrait te renvoyer : LoginMaster

Et enfin

Code :

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

? Forms.FO2100_PST.FO2200_PASS.Form.LoginMaster

il devrait renvoyer la valeur de LoginMaster.

Indique-moi à quel moment ça plante.

[Access_ible]

Bonsoir.

Merci de continuer à m'apporter votre soutien.

L'aide, c'est bien, les contributions, c'est mieux, le bon diagnostique, c'est à cela que l'on reconnaît la crème des aficionados de ce site dont vous faites définitivement partie.

Ne vous inquiétez pas, le fin mot de l'histoire arrive…

Il est maintenant évident, comme vous l'aviez déjà indiqué, qu'aussi sûrement que je n'ai pas correctement envoyé la copie conforme de ce que j'ai saisi comme valeur pour getValueControl, j'ai du me planter tout autant pour le texte SQL que je tentais de faire interpréter par DAO_GenericOpenRecordset.

Mea Culpa...

Mais je ne suis pas pour autant un foufou qui fonce sans savoir et qui mélange des trucs en espérant arriver à ses fins.

C'est une succession d'écarts plus que d'erreurs qui est à l'origine de ce qui s'est passé.

En fait, encore une fois comme vous aviez raison de l'indiquer, la requête ne fonctionnait pas non plus dans l'assistant de requête.

Access me demandais la valeur du contrôle que j'indiquais comme critère et j'interprétais cette demande comme étant du au fait que le formulaire n'était pas chargé.
Je rentrais la valeur et ça marchait, comme je l'ai déjà fais des dizaines de fois pour tester une requête sur un contrôle d'un formulaire non ouvert…

Alors qu'en fait, c'est parce que l'erreur d'appel que vous avez souligné faisait qu'Access ne comprenait pas à quel objet je faisais allusion…

L'autre écart a été de tester le DAO_GenericOpenRecordset sur un formulaire conçu, mais pas encore paramétré pour, dans un futur proche, se comporter selon le système de Philippe JOCHMANS.

Peut-être voyez-vous déjà ce qui s'est passé…

Bonjour,
Procédons par ordre pour tenter de cerner le problème.
[…]
Puis poursuis par :

Code :

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

? Forms.FO2100_PST.FO2200_PASS.name

il devrait te renvoyer : FO2200_PASS
[…]

Et bien non, il ne renvoi pas FO2200_PASS !

Et ça m'a vraiment surpris pendant 1 minute montre en main, avant que je réalise que dans le système de Philippe JOCHMANS, le sous formulaire ne porte pas le nom du formulaire source, mais celui d'un contrôle à part !

Même si j'avais pris soin, pour la phase de test d'indiquer "en dur" que la source du sous formulaire était FO2200_PASS, je n'ai pas changé le nom pour autant.

Du coup, dans l'arborescence des (sous) formulaires, il n'y avait aucune chance qu'il retrouve FO2200_PASS.Form.LoginMaster !

Voici le code que je saisi maintenant sur la ligne SQL destinée à DAO_GenericOpenRecordset

Code :

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

1
2
3
4
SELECT First(TB0110_UTLSTR.UTLSTR_LGN) AS PremierDeUTLSTR_LGN, TB0110_UTLSTR.UTLSTR_MDP, TB0110_UTLSTR.UTLSTR_NM, TB0110_UTLSTR.UTLSTR_PRNM, TB0110_UTLSTR.UTLSTR_ACCSS
FROM TB0110_UTLSTR
GROUP BY TB0110_UTLSTR.UTLSTR_MDP, TB0110_UTLSTR.UTLSTR_NM, TB0110_UTLSTR.UTLSTR_PRNM, TB0110_UTLSTR.UTLSTR_ACCSS
HAVING (((First(TB0110_UTLSTR.UTLSTR_LGN))=Formulaires!FO2100_PST!CTRL_SBFRM_01.Form!LoginMaster));

Comme précédemment, cette ligne est issue de l'assistant requête d'Access.

Comme précédemment, si je lance cette requête, j'ai une message box où je doit saisir la valeur.

Mais je sais maintenant que l'intitulé précis de cette message box est différent de celui lié à une erreur d'appel, et aussi de celui lié à une erreur de nom de sous formulaire.

Maintenant tout fonctionne, y compris DAO_GenericOpenRecordset sans même passer par la fonction getValueControl.

Mais ça ne me surprend qu'à moitié, comme je l'ai indiqué à plusieurs reprises, je n'ai pas les compétences pour déterminer ce que DAO_GenericOpenRecordset est capable de faire ou non, cela signifiait aussi que je n'excluait pas un autre problème, même si j'étais sur que l'appel SQL fonctionnait, pour les raisons détaillées ci avant.

C'est vraiment votre intervention avec cette façon de cerner le problème et l'erreur en réponse de ? Forms.FO2100_PST.FO2200_PASS.name qui m'ont fait prendre conscience des tenants et des aboutissants de mon problème.

Encore un immense merci à vous, pour ce coup-ci et pour tout ce que faites par ailleurs pour les utilisateurs d'Access.

Merci.

[loufab]

Bonjour,
Voici une fin heureuse !

Le cas du sous-formulaire qui n'a pas le même nom que son container est assez classique.
Dans l'appel il s'agit toujours du non de ce container. Pas commodité on ne met pas le même nom pour les 2. On évite ainsi le mélange.

La syntaxe serait donc :

Code :

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

forms.NomDuFormPrincipal.NomDuContainerDuSousForm.Form.

Bref ! dés qu'il y a doute revenir à la bonne vieille méthode de décomposer l'instruction, c'est valable pour toutes les instructions d'ailleurs.

Cordialement,

[Access_ible]

Bonjour.

C'est notamment grâce au présent échange que j'ai pu découvrir cette commande utilisée en diagnostique, qui m'aurait déjà servi…

Encore un grand merci à vous pour tout.