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
Drizzit
Pour maintenir une application il est impératif de mettre en place une gestion des erreurs. Ceci se fait, en principe, par l'instruction, que tu colles en début de toutes procédures et fonction : On Error Goto GestionDesErreurs
et en fin de procédures / fonction, tu mets ton étiquette GestionDesErreurs: MsgBox "Erreur n°" & Err.Number & " - " & Err.Description & vbcrlf & "Dans la procédure Toto"
Ceci te permettrait de savoir dans quelle procédure / fonction ça merde. Ensuite, pour être plus préci dans cette procédure / fonction, tu peux numéroté les lignes, et ensuite remplacer par : MsgBox "Erreur n°" & Err.Number & " - " & Err.Description & vbcrlf & "Dans la procédure Toto à la ligne " & Erl
Maintenant, cette gestion des erreurs est simplifiée. L'idéale serait de créer une procédure publique que tu appelles dans toutes tes étiquettes de gestion d'erreurs. On peut même pousser le bouchon en gérant la pile des appels des procédures / fonctions en diffusant l'erreur au procédure / fonction appelante...
Conclusion : ajoute des gestions d'erreur partout, même si ca semble con... Au moins, quand ça plante, tu sais où ça plante...
Pour maintenir une application il est impératif de mettre en place une
gestion des erreurs.
Ceci se fait, en principe,
par l'instruction, que tu colles en début de toutes procédures et
fonction :
On Error Goto GestionDesErreurs
et en fin de procédures / fonction, tu mets ton étiquette
GestionDesErreurs:
MsgBox "Erreur n°" & Err.Number & " - " & Err.Description & vbcrlf &
"Dans la procédure Toto"
Ceci te permettrait de savoir dans quelle procédure / fonction ça
merde. Ensuite, pour être plus préci dans cette procédure /
fonction, tu peux numéroté les lignes, et ensuite remplacer par :
MsgBox "Erreur n°" & Err.Number & " - " & Err.Description & vbcrlf &
"Dans la procédure Toto à la ligne " & Erl
Maintenant, cette gestion des erreurs est simplifiée.
L'idéale serait de créer une procédure publique que tu appelles dans
toutes tes étiquettes de gestion d'erreurs. On peut même pousser le
bouchon en gérant la pile des appels des procédures / fonctions en
diffusant l'erreur au procédure / fonction appelante...
Conclusion :
ajoute des gestions d'erreur partout, même si ca semble con... Au
moins, quand ça plante, tu sais où ça plante...
Pour maintenir une application il est impératif de mettre en place une gestion des erreurs. Ceci se fait, en principe, par l'instruction, que tu colles en début de toutes procédures et fonction : On Error Goto GestionDesErreurs
et en fin de procédures / fonction, tu mets ton étiquette GestionDesErreurs: MsgBox "Erreur n°" & Err.Number & " - " & Err.Description & vbcrlf & "Dans la procédure Toto"
Ceci te permettrait de savoir dans quelle procédure / fonction ça merde. Ensuite, pour être plus préci dans cette procédure / fonction, tu peux numéroté les lignes, et ensuite remplacer par : MsgBox "Erreur n°" & Err.Number & " - " & Err.Description & vbcrlf & "Dans la procédure Toto à la ligne " & Erl
Maintenant, cette gestion des erreurs est simplifiée. L'idéale serait de créer une procédure publique que tu appelles dans toutes tes étiquettes de gestion d'erreurs. On peut même pousser le bouchon en gérant la pile des appels des procédures / fonctions en diffusant l'erreur au procédure / fonction appelante...
Conclusion : ajoute des gestions d'erreur partout, même si ca semble con... Au moins, quand ça plante, tu sais où ça plante...
Yttrium
Drizzit a écrit :
Conclusion : ajoute des gestions d'erreur partout, même si ca semble con... Au moins, quand ça plante, tu sais où ça plante...
Certes, mais comment cela peut il planter à l'execution, et pas en mode debogage ? C'est bien cela qui me surprend?
-- [- Yttrium - http://www.danstesyeux.com -] Le temps ne fait rien à l'affaire, quand on est con... on est con...
Drizzit a écrit :
Conclusion :
ajoute des gestions d'erreur partout, même si ca semble con... Au
moins, quand ça plante, tu sais où ça plante...
Certes, mais comment cela peut il planter à l'execution, et pas en mode
debogage ?
C'est bien cela qui me surprend?
--
[- Yttrium - http://www.danstesyeux.com -]
Le temps ne fait rien à l'affaire, quand on est con...
on est con...
Certes, mais comment cela peut il planter à l'execution, et pas en mode debogage ? C'est bien cela qui me surprend?
Les exe ont besoin de dll, ocx ... que tu n'as pas dû installer.
Drizzit
Ne connaissant pas ton application, il est impossible de répondre. Les causes peuvent être multiples. - version ocx différente - version dll différente - Setting de ton os - Niveau de Service Pack différent - données de ton utilisateur qui sont différentes des tiennes - .........
Le but surtout est de savoir où sa plante. Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas de MDAC, où une versio antérieure à celle que toi tu utilises en développement. Là si tu donnes ce genre d'information, on peut t'aider.
Ne connaissant pas ton application, il est impossible de répondre.
Les causes peuvent être multiples.
- version ocx différente
- version dll différente
- Setting de ton os
- Niveau de Service Pack différent
- données de ton utilisateur qui sont différentes des tiennes
- .........
Le but surtout est de savoir où sa plante.
Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New
ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas
de MDAC, où une versio antérieure à celle que toi tu utilises en
développement.
Là si tu donnes ce genre d'information, on peut t'aider.
Ne connaissant pas ton application, il est impossible de répondre. Les causes peuvent être multiples. - version ocx différente - version dll différente - Setting de ton os - Niveau de Service Pack différent - données de ton utilisateur qui sont différentes des tiennes - .........
Le but surtout est de savoir où sa plante. Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas de MDAC, où une versio antérieure à celle que toi tu utilises en développement. Là si tu donnes ce genre d'information, on peut t'aider.
Yttrium
Drizzit a écrit :
Ne connaissant pas ton application, il est impossible de répondre. Les causes peuvent être multiples. - version ocx différente - version dll différente - Setting de ton os - Niveau de Service Pack différent - données de ton utilisateur qui sont différentes des tiennes - .........
Le but surtout est de savoir où sa plante. Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas de MDAC, où une versio antérieure à celle que toi tu utilises en développement. Là si tu donnes ce genre d'information, on peut t'aider.
Je précise que le probleme a lieu sur le MEME poste, selon que j'execute le logiciel que je viens de compiler (sur ce poste) ou bien que je l'execute au sein de Vb en debogage..
-- [- Yttrium - http://www.danstesyeux.com -] Le temps ne fait rien à l'affaire, quand on est con... on est con...
Drizzit a écrit :
Ne connaissant pas ton application, il est impossible de répondre.
Les causes peuvent être multiples.
- version ocx différente
- version dll différente
- Setting de ton os
- Niveau de Service Pack différent
- données de ton utilisateur qui sont différentes des tiennes
- .........
Le but surtout est de savoir où sa plante.
Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New
ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas
de MDAC, où une versio antérieure à celle que toi tu utilises en
développement.
Là si tu donnes ce genre d'information, on peut t'aider.
Je précise que le probleme a lieu sur le MEME poste, selon que j'execute
le logiciel que je viens de compiler (sur ce poste) ou bien que je
l'execute au sein de Vb en debogage..
--
[- Yttrium - http://www.danstesyeux.com -]
Le temps ne fait rien à l'affaire, quand on est con...
on est con...
Ne connaissant pas ton application, il est impossible de répondre. Les causes peuvent être multiples. - version ocx différente - version dll différente - Setting de ton os - Niveau de Service Pack différent - données de ton utilisateur qui sont différentes des tiennes - .........
Le but surtout est de savoir où sa plante. Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas de MDAC, où une versio antérieure à celle que toi tu utilises en développement. Là si tu donnes ce genre d'information, on peut t'aider.
Je précise que le probleme a lieu sur le MEME poste, selon que j'execute le logiciel que je viens de compiler (sur ce poste) ou bien que je l'execute au sein de Vb en debogage..
-- [- Yttrium - http://www.danstesyeux.com -] Le temps ne fait rien à l'affaire, quand on est con... on est con...
Jacques93
Bonjour Yttrium, Yttrium a écrit :
Drizzit a écrit :
Ne connaissant pas ton application, il est impossible de répondre. Les causes peuvent être multiples. - version ocx différente - version dll différente - Setting de ton os - Niveau de Service Pack différent - données de ton utilisateur qui sont différentes des tiennes - .........
Le but surtout est de savoir où sa plante. Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas de MDAC, où une versio antérieure à celle que toi tu utilises en développement. Là si tu donnes ce genre d'information, on peut t'aider.
Je précise que le probleme a lieu sur le MEME poste, selon que j'execute le logiciel que je viens de compiler (sur ce poste) ou bien que je l'execute au sein de Vb en debogage..
Il m'est arrivé d'avoir l'erreur d'execution '5'
Argument ou appel de procédure incorrect
lors de l'utilisation de certaines méthodes avec un executable, et pas dans l'IDE. Pas de manière systèmatique, mais par exemple :
Ctl.Visible = True Ctl.SetFocus
Dans certains cas, le SetFocus plantait en Erreur 5, car manifestement le contrôle n'était pas visible. VB semble ne pas toujours fonctionner de manière synchrone (ou les API's qu'il utilise)
C'est effectivement délicat à localiser, sauf a mettre en place un gestion d'erreur.
Je suppose que d'autres cas de figure peuvent avoir le même effet : l'utilisation d'une méthode sur un contrôle dont une propriété ne permet pas d'utiliser cette méthode.
-- Cordialement,
Jacques.
Bonjour Yttrium,
Yttrium a écrit :
Drizzit a écrit :
Ne connaissant pas ton application, il est impossible de répondre.
Les causes peuvent être multiples.
- version ocx différente
- version dll différente
- Setting de ton os
- Niveau de Service Pack différent
- données de ton utilisateur qui sont différentes des tiennes
- .........
Le but surtout est de savoir où sa plante.
Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New
ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas
de MDAC, où une versio antérieure à celle que toi tu utilises en
développement.
Là si tu donnes ce genre d'information, on peut t'aider.
Je précise que le probleme a lieu sur le MEME poste, selon que j'execute
le logiciel que je viens de compiler (sur ce poste) ou bien que je
l'execute au sein de Vb en debogage..
Il m'est arrivé d'avoir l'erreur d'execution '5'
Argument ou appel de procédure incorrect
lors de l'utilisation de certaines méthodes avec un executable, et pas
dans l'IDE. Pas de manière systèmatique, mais par exemple :
Ctl.Visible = True
Ctl.SetFocus
Dans certains cas, le SetFocus plantait en Erreur 5, car manifestement
le contrôle n'était pas visible. VB semble ne pas toujours fonctionner
de manière synchrone (ou les API's qu'il utilise)
C'est effectivement délicat à localiser, sauf a mettre en place un
gestion d'erreur.
Je suppose que d'autres cas de figure peuvent avoir le même effet :
l'utilisation d'une méthode sur un contrôle dont une propriété ne permet
pas d'utiliser cette méthode.
Ne connaissant pas ton application, il est impossible de répondre. Les causes peuvent être multiples. - version ocx différente - version dll différente - Setting de ton os - Niveau de Service Pack différent - données de ton utilisateur qui sont différentes des tiennes - .........
Le but surtout est de savoir où sa plante. Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas de MDAC, où une versio antérieure à celle que toi tu utilises en développement. Là si tu donnes ce genre d'information, on peut t'aider.
Je précise que le probleme a lieu sur le MEME poste, selon que j'execute le logiciel que je viens de compiler (sur ce poste) ou bien que je l'execute au sein de Vb en debogage..
Il m'est arrivé d'avoir l'erreur d'execution '5'
Argument ou appel de procédure incorrect
lors de l'utilisation de certaines méthodes avec un executable, et pas dans l'IDE. Pas de manière systèmatique, mais par exemple :
Ctl.Visible = True Ctl.SetFocus
Dans certains cas, le SetFocus plantait en Erreur 5, car manifestement le contrôle n'était pas visible. VB semble ne pas toujours fonctionner de manière synchrone (ou les API's qu'il utilise)
C'est effectivement délicat à localiser, sauf a mettre en place un gestion d'erreur.
Je suppose que d'autres cas de figure peuvent avoir le même effet : l'utilisation d'une méthode sur un contrôle dont une propriété ne permet pas d'utiliser cette méthode.
-- Cordialement,
Jacques.
Patrice Henrio
Il m'est arrivé ce problème lorsque le temps de chargement d'un contrôle ou d'un texte est "long" (tout est relatif avec nos processeurs actuels). En mode IDE, le temps d'exécution est ralenti et le contrôle a le temps de s'initialiser, en mode EXE non et on fait appel à une propriété d'un objet n'existant pas encore.
"Jacques93" a écrit dans le message de news:
Bonjour Yttrium, Yttrium a écrit :
Drizzit a écrit :
Ne connaissant pas ton application, il est impossible de répondre. Les causes peuvent être multiples. - version ocx différente - version dll différente - Setting de ton os - Niveau de Service Pack différent - données de ton utilisateur qui sont différentes des tiennes - .........
Le but surtout est de savoir où sa plante. Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas de MDAC, où une versio antérieure à celle que toi tu utilises en développement. Là si tu donnes ce genre d'information, on peut t'aider.
Je précise que le probleme a lieu sur le MEME poste, selon que j'execute le logiciel que je viens de compiler (sur ce poste) ou bien que je l'execute au sein de Vb en debogage..
Il m'est arrivé d'avoir l'erreur d'execution '5'
Argument ou appel de procédure incorrect
lors de l'utilisation de certaines méthodes avec un executable, et pas dans l'IDE. Pas de manière systèmatique, mais par exemple :
Ctl.Visible = True Ctl.SetFocus
Dans certains cas, le SetFocus plantait en Erreur 5, car manifestement le contrôle n'était pas visible. VB semble ne pas toujours fonctionner de manière synchrone (ou les API's qu'il utilise)
C'est effectivement délicat à localiser, sauf a mettre en place un gestion d'erreur.
Je suppose que d'autres cas de figure peuvent avoir le même effet : l'utilisation d'une méthode sur un contrôle dont une propriété ne permet pas d'utiliser cette méthode.
-- Cordialement,
Jacques.
Il m'est arrivé ce problème lorsque le temps de chargement d'un contrôle ou
d'un texte est "long" (tout est relatif avec nos processeurs actuels). En
mode IDE, le temps d'exécution est ralenti et le contrôle a le temps de
s'initialiser, en mode EXE non et on fait appel à une propriété d'un objet
n'existant pas encore.
"Jacques93" <jacques@Nospam> a écrit dans le message de news:
OQ9LdczKGHA.3896@TK2MSFTNGP15.phx.gbl...
Bonjour Yttrium,
Yttrium a écrit :
Drizzit a écrit :
Ne connaissant pas ton application, il est impossible de répondre.
Les causes peuvent être multiples.
- version ocx différente
- version dll différente
- Setting de ton os
- Niveau de Service Pack différent
- données de ton utilisateur qui sont différentes des tiennes
- .........
Le but surtout est de savoir où sa plante.
Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New
ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas
de MDAC, où une versio antérieure à celle que toi tu utilises en
développement.
Là si tu donnes ce genre d'information, on peut t'aider.
Je précise que le probleme a lieu sur le MEME poste, selon que j'execute
le logiciel que je viens de compiler (sur ce poste) ou bien que je
l'execute au sein de Vb en debogage..
Il m'est arrivé d'avoir l'erreur d'execution '5'
Argument ou appel de procédure incorrect
lors de l'utilisation de certaines méthodes avec un executable, et pas
dans l'IDE. Pas de manière systèmatique, mais par exemple :
Ctl.Visible = True
Ctl.SetFocus
Dans certains cas, le SetFocus plantait en Erreur 5, car manifestement le
contrôle n'était pas visible. VB semble ne pas toujours fonctionner de
manière synchrone (ou les API's qu'il utilise)
C'est effectivement délicat à localiser, sauf a mettre en place un gestion
d'erreur.
Je suppose que d'autres cas de figure peuvent avoir le même effet :
l'utilisation d'une méthode sur un contrôle dont une propriété ne permet
pas d'utiliser cette méthode.
Il m'est arrivé ce problème lorsque le temps de chargement d'un contrôle ou d'un texte est "long" (tout est relatif avec nos processeurs actuels). En mode IDE, le temps d'exécution est ralenti et le contrôle a le temps de s'initialiser, en mode EXE non et on fait appel à une propriété d'un objet n'existant pas encore.
"Jacques93" a écrit dans le message de news:
Bonjour Yttrium, Yttrium a écrit :
Drizzit a écrit :
Ne connaissant pas ton application, il est impossible de répondre. Les causes peuvent être multiples. - version ocx différente - version dll différente - Setting de ton os - Niveau de Service Pack différent - données de ton utilisateur qui sont différentes des tiennes - .........
Le but surtout est de savoir où sa plante. Ainsi, si tu sais que sa plante sur l'instruction Set objRs = New ADODB.Recordset, par exemple, ben c'est peut être que le poste n'a pas de MDAC, où une versio antérieure à celle que toi tu utilises en développement. Là si tu donnes ce genre d'information, on peut t'aider.
Je précise que le probleme a lieu sur le MEME poste, selon que j'execute le logiciel que je viens de compiler (sur ce poste) ou bien que je l'execute au sein de Vb en debogage..
Il m'est arrivé d'avoir l'erreur d'execution '5'
Argument ou appel de procédure incorrect
lors de l'utilisation de certaines méthodes avec un executable, et pas dans l'IDE. Pas de manière systèmatique, mais par exemple :
Ctl.Visible = True Ctl.SetFocus
Dans certains cas, le SetFocus plantait en Erreur 5, car manifestement le contrôle n'était pas visible. VB semble ne pas toujours fonctionner de manière synchrone (ou les API's qu'il utilise)
C'est effectivement délicat à localiser, sauf a mettre en place un gestion d'erreur.
Je suppose que d'autres cas de figure peuvent avoir le même effet : l'utilisation d'une méthode sur un contrôle dont une propriété ne permet pas d'utiliser cette méthode.
