J'ai un petit souci avec certains rapports qui fonctionnaient correctement
sous access2003.
A l'ouverture du rapport, lorsqu'un un code événement du type
"Report_Activate()" attribue le résultat d'un calcul à un champ indépendant,
celui-ci reste vide.
Quelqu'un aurait il une explication à ce problème sur lequel je butte.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
Salut,
"D.Schneider" | J'ai un petit souci avec certains rapports qui fonctionnaient correctement | sous access2003. | A l'ouverture du rapport, lorsqu'un un code événement du type | "Report_Activate()" attribue le résultat d'un calcul à un champ indépendant, | celui-ci reste vide. | Quelqu'un aurait il une explication à ce problème sur lequel je butte.
As-tu installer la SR1 pour voir si cela était corrigé ?
"D.Schneider"
| J'ai un petit souci avec certains rapports qui fonctionnaient correctement
| sous access2003.
| A l'ouverture du rapport, lorsqu'un un code événement du type
| "Report_Activate()" attribue le résultat d'un calcul à un champ indépendant,
| celui-ci reste vide.
| Quelqu'un aurait il une explication à ce problème sur lequel je butte.
As-tu installer la SR1 pour voir si cela était corrigé ?
"D.Schneider" | J'ai un petit souci avec certains rapports qui fonctionnaient correctement | sous access2003. | A l'ouverture du rapport, lorsqu'un un code événement du type | "Report_Activate()" attribue le résultat d'un calcul à un champ indépendant, | celui-ci reste vide. | Quelqu'un aurait il une explication à ce problème sur lequel je butte.
As-tu installer la SR1 pour voir si cela était corrigé ?
"D.Schneider" | J'ai un petit souci avec certains rapports qui fonctionnaient correctement | sous access2003. | A l'ouverture du rapport, lorsqu'un un code événement du type | "Report_Activate()" attribue le résultat d'un calcul à un champ indépendant, | celui-ci reste vide. | Quelqu'un aurait il une explication à ce problème sur lequel je butte.
As-tu installer la SR1 pour voir si cela était corrigé ?
Je viens d'installer SR1, mais cela n'apporte aucune amélioration. Mais j'ai aussi remarqué certaines étrangetés: Si dans le code suivant, je remplace: acViewPreview par ViewReport, le résultat s'affiche dans le champ de l'entête de page, mais le rapport ne se présente plus page par page , mais sous forme continue. **************** stDocName = "Table_Report_Total_Plus" DoCmd.OpenReport stDocName, acViewPreview DoCmd.Maximize
Autre phénomène constaté , lorsque mon code contient une erreur non gérée par On Error..., au lieu de bloquer sur la ligne qui contient l'erreur (jaune fluo), il ne se lance tout simplement pas. Enfin, je n'arrive pas à avoir le Help habituel lorsque j'appuie sur la touche F1 après avoir sélectionné un objet VBA. C'est la fenêtre standard d'aide online avec des généralités genre "comment faire... dans access 2007" qui se présente. Je commence à regretter d'avoir installé la version 2007 d'Office à la place de 2003.
Merci de ton aide, Denis
"3stone" <home@sweet_home.be> a écrit dans le message de news:
eLPi2REXIHA.5208@TK2MSFTNGP04.phx.gbl...
Salut,
"D.Schneider"
| J'ai un petit souci avec certains rapports qui fonctionnaient
correctement
| sous access2003.
| A l'ouverture du rapport, lorsqu'un un code événement du type
| "Report_Activate()" attribue le résultat d'un calcul à un champ
indépendant,
| celui-ci reste vide.
| Quelqu'un aurait il une explication à ce problème sur lequel je butte.
As-tu installer la SR1 pour voir si cela était corrigé ?
Je viens d'installer SR1, mais cela n'apporte aucune amélioration.
Mais j'ai aussi remarqué certaines étrangetés:
Si dans le code suivant, je remplace: acViewPreview par ViewReport, le
résultat s'affiche dans le champ de l'entête de page,
mais le rapport ne se présente plus page par page , mais sous forme
continue.
****************
stDocName = "Table_Report_Total_Plus"
DoCmd.OpenReport stDocName, acViewPreview
DoCmd.Maximize
Autre phénomène constaté , lorsque mon code contient une erreur non gérée
par On Error...,
au lieu de bloquer sur la ligne qui contient l'erreur (jaune fluo), il ne se
lance tout simplement pas.
Enfin, je n'arrive pas à avoir le Help habituel lorsque j'appuie sur la
touche F1 après avoir sélectionné un objet VBA.
C'est la fenêtre standard d'aide online avec des généralités genre "comment
faire... dans access 2007" qui se présente.
Je commence à regretter d'avoir installé la version 2007 d'Office à la place
de 2003.
"D.Schneider" | J'ai un petit souci avec certains rapports qui fonctionnaient correctement | sous access2003. | A l'ouverture du rapport, lorsqu'un un code événement du type | "Report_Activate()" attribue le résultat d'un calcul à un champ indépendant, | celui-ci reste vide. | Quelqu'un aurait il une explication à ce problème sur lequel je butte.
As-tu installer la SR1 pour voir si cela était corrigé ?
Je viens d'installer SR1, mais cela n'apporte aucune amélioration. Mais j'ai aussi remarqué certaines étrangetés: Si dans le code suivant, je remplace: acViewPreview par ViewReport, le résultat s'affiche dans le champ de l'entête de page, mais le rapport ne se présente plus page par page , mais sous forme continue. **************** stDocName = "Table_Report_Total_Plus" DoCmd.OpenReport stDocName, acViewPreview DoCmd.Maximize
Autre phénomène constaté , lorsque mon code contient une erreur non gérée par On Error..., au lieu de bloquer sur la ligne qui contient l'erreur (jaune fluo), il ne se lance tout simplement pas. Enfin, je n'arrive pas à avoir le Help habituel lorsque j'appuie sur la touche F1 après avoir sélectionné un objet VBA. C'est la fenêtre standard d'aide online avec des généralités genre "comment faire... dans access 2007" qui se présente. Je commence à regretter d'avoir installé la version 2007 d'Office à la place de 2003.
Merci de ton aide, Denis
Gloops
D.Schneider a écrit, le 23/01/2008 18:20 :
Autre phénomène constaté , lorsque mon code contient une erreur n on gérée par On Error..., au lieu de bloquer sur la ligne qui contient l'erreur (jaune fluo), il ne se lance tout simplement pas.
Salut,
Non, c'est pas vrai, Access arrête de cafter ? ;) En un mot : bravo.
En procédure d'erreur, je verrais bien tester la présence d'un formulaire frmTest, et si il est là : Stop, Resume.
Et avec deux fois la touche F8 on se retrouve pile sur l'erreur.
Alors que si frmTest n'est pas chargé l'utilisateur final a une boîte de message qui lui dit quoi dire au programmeur (le fin du fin étant un formulaire permettant de copier le message dans le presse-papiers), et on ne l'invite pas à plonger dans le code et tout casser de ses grosses pattes velues :)
(non mais c'est quoi ces histoires de ligne en jaune fluo à présenter à quelqu'un qui vient de découvrir ce que c'est qu'un clavier, ce que c'est qu'une souris, et qu'on peut faire autre chose avec qu'exciter le chat ? ;) )
Exit Sub erreurProcedure:
MsgBox "Error n° " + VBA.Str$(Err.Number) + " in " + Err.Source + _ " : " + vbCrLf + Err.Description,,"Ici le nom de la procédure" If ExisteFormulaire("frmTest") Then Stop Resume End If End Sub
Pour ExisteFormulaire, deux formules possibles : parcourir la collection Forms dans une boucle et comparer les noms à celui recherché, ou utiliser SysCmd(acSysCmdGetObjectState, acForm, formname). On trouve une troisième version basée sur la détection d'erreur ici (ExistForm) : http://www.developpez.net/forums/showthread.php?td923 Attention de bien tester ce qu'on fait si on utilise un code basé sur l a détection d'erreurs ... dans une procédure d'erreurs.
On peut aussi discuter optimisation : il y a peut-être moins gourmand e n ressources pour établir une condition facilement que de tester l'existence d'un formulaire ?
D.Schneider a écrit, le 23/01/2008 18:20 :
Autre phénomène constaté , lorsque mon code contient une erreur n on gérée
par On Error...,
au lieu de bloquer sur la ligne qui contient l'erreur (jaune fluo), il ne se
lance tout simplement pas.
Salut,
Non, c'est pas vrai, Access arrête de cafter ? ;)
En un mot : bravo.
En procédure d'erreur, je verrais bien tester la présence d'un
formulaire frmTest, et si il est là : Stop, Resume.
Et avec deux fois la touche F8 on se retrouve pile sur l'erreur.
Alors que si frmTest n'est pas chargé l'utilisateur final a une boîte de
message qui lui dit quoi dire au programmeur (le fin du fin étant un
formulaire permettant de copier le message dans le presse-papiers), et
on ne l'invite pas à plonger dans le code et tout casser de ses grosses
pattes velues :)
(non mais c'est quoi ces histoires de ligne en jaune fluo à présenter à
quelqu'un qui vient de découvrir ce que c'est qu'un clavier, ce que
c'est qu'une souris, et qu'on peut faire autre chose avec qu'exciter le
chat ? ;) )
Exit Sub
erreurProcedure:
MsgBox "Error n° " + VBA.Str$(Err.Number) + " in " + Err.Source + _
" : " + vbCrLf + Err.Description,,"Ici le nom de la procédure"
If ExisteFormulaire("frmTest") Then
Stop
Resume
End If
End Sub
Pour ExisteFormulaire, deux formules possibles : parcourir la collection
Forms dans une boucle et comparer les noms à celui recherché, ou
utiliser SysCmd(acSysCmdGetObjectState, acForm, formname).
On trouve une troisième version basée sur la détection d'erreur ici
(ExistForm) :
http://www.developpez.net/forums/showthread.php?t=64923
Attention de bien tester ce qu'on fait si on utilise un code basé sur l a
détection d'erreurs ... dans une procédure d'erreurs.
On peut aussi discuter optimisation : il y a peut-être moins gourmand e n
ressources pour établir une condition facilement que de tester
l'existence d'un formulaire ?
Autre phénomène constaté , lorsque mon code contient une erreur n on gérée par On Error..., au lieu de bloquer sur la ligne qui contient l'erreur (jaune fluo), il ne se lance tout simplement pas.
Salut,
Non, c'est pas vrai, Access arrête de cafter ? ;) En un mot : bravo.
En procédure d'erreur, je verrais bien tester la présence d'un formulaire frmTest, et si il est là : Stop, Resume.
Et avec deux fois la touche F8 on se retrouve pile sur l'erreur.
Alors que si frmTest n'est pas chargé l'utilisateur final a une boîte de message qui lui dit quoi dire au programmeur (le fin du fin étant un formulaire permettant de copier le message dans le presse-papiers), et on ne l'invite pas à plonger dans le code et tout casser de ses grosses pattes velues :)
(non mais c'est quoi ces histoires de ligne en jaune fluo à présenter à quelqu'un qui vient de découvrir ce que c'est qu'un clavier, ce que c'est qu'une souris, et qu'on peut faire autre chose avec qu'exciter le chat ? ;) )
Exit Sub erreurProcedure:
MsgBox "Error n° " + VBA.Str$(Err.Number) + " in " + Err.Source + _ " : " + vbCrLf + Err.Description,,"Ici le nom de la procédure" If ExisteFormulaire("frmTest") Then Stop Resume End If End Sub
Pour ExisteFormulaire, deux formules possibles : parcourir la collection Forms dans une boucle et comparer les noms à celui recherché, ou utiliser SysCmd(acSysCmdGetObjectState, acForm, formname). On trouve une troisième version basée sur la détection d'erreur ici (ExistForm) : http://www.developpez.net/forums/showthread.php?td923 Attention de bien tester ce qu'on fait si on utilise un code basé sur l a détection d'erreurs ... dans une procédure d'erreurs.
On peut aussi discuter optimisation : il y a peut-être moins gourmand e n ressources pour établir une condition facilement que de tester l'existence d'un formulaire ?
