... controle des données saisies
...et dans certains cas message d'erreur
Cancel = True
end sub
Dans ce cas la valeur saisie est effacée et le curseur se repositionne sur
le champ.
Mais si je veux écrire une procédure Public en passant comme paramètre
myField comment faire pour le Cancel = True ?
J'ai essayé en testant le résultat du style if... then Cancel = True mais ça
ne fonctionne pas
J'aurais préféré utiliser la procédure qu'une fonction car je n'aurais eu à mettre qu'une ligne d'appel par zone à contrôler alors qu'avec la fonction ça fait quand même un petit bloc par zone.
Mauvais argument. Du code un poil plus long mais clair et modulaire est **toujours** un gain de temps et un gage de qualité.
Mais, d'une part je n'arrive pas à faire fonctionner correctement l'appel à la procédure (en fait le cancel ne fait rien) Je peux toujours réinitialiser le champ dans la procédure mais je ne vois pas comment lui redonner le focus.
C'est certainement parce que tu tombes dans le piège classique des arguments byval/byref dans les procédures. C'est un grand classique, tu trouveras la solution ici: http://faq.vb.free.fr/index.php?question#
Pour ce qui est de mélanger les MsgBox avec les instructions de vérification, j'en ai besoin car selon l'erreur le message n'est pas le même.
Mauvais argument. Rien n'interdit à ta fonction d'etre intelligente et de retourner une variable qui contient la raison de l'erreur:
Par exemple:
Private Function checkDate(ByVal aDate As String, ByRef errMsg As String) As Boolean
If IsDate(aDate) Then If CDate(aDate) > CDate(Now) Then errMsg = "Date postérieure à la date du jour" checkDate = False Else checkDate = True End If Else errMsg = "Format de date non valide" checkDate = False End If End Function
puis:
Dim s As String Dim errMsg As String
s = Text1.Text ret = checkDate(s, errMsg) If Not ret Then MsgBox errMsg Else ' ... End If
En faisant un design comme celui-ci pour CheckDate(), je garde un découpage clair entre fonctionnel et interface. Demain je peux me reservir de ma fonction dans un autre programme sans problème. Ma fonction est indépendante.
Rappel de la règle N°1: "A chacun son métier, et les vaches seront bien gardées.".
Ca s'applique aussi à la programmation : une fonction doit faire son boulot, rien de moins et rien de plus.
Ce genre de chose est la base de la programmation structurée. Il a toujours plein de mauvaises =>excuses<= pour faire un mauvais design, mais jamais de vraies =>raisons<= :-)
"jerome" <jerome@hh.fr> wrote in message
news:utY8mU9GIHA.2328@TK2MSFTNGP03.phx.gbl...
J'aurais préféré utiliser la procédure qu'une fonction car je n'aurais eu
à
mettre qu'une ligne d'appel par zone à contrôler alors qu'avec la fonction
ça fait quand même un petit bloc par zone.
Mauvais argument. Du code un poil plus long mais clair
et modulaire est **toujours** un gain de temps et un
gage de qualité.
Mais, d'une part je n'arrive pas à faire fonctionner correctement l'appel
à
la procédure (en fait le cancel ne fait rien) Je peux toujours
réinitialiser
le champ dans la procédure mais je ne vois pas comment lui redonner le
focus.
C'est certainement parce que tu tombes dans le piège classique
des arguments byval/byref dans les procédures. C'est un grand
classique, tu trouveras la solution ici:
http://faq.vb.free.fr/index.php?question#
Pour ce qui est de mélanger les MsgBox avec les instructions de
vérification, j'en ai besoin car selon l'erreur le message n'est pas le
même.
Mauvais argument. Rien n'interdit à ta fonction d'etre
intelligente et de retourner une variable qui contient
la raison de l'erreur:
Par exemple:
Private Function checkDate(ByVal aDate As String, ByRef errMsg As String) As
Boolean
If IsDate(aDate) Then
If CDate(aDate) > CDate(Now) Then
errMsg = "Date postérieure à la date du jour"
checkDate = False
Else
checkDate = True
End If
Else
errMsg = "Format de date non valide"
checkDate = False
End If
End Function
puis:
Dim s As String
Dim errMsg As String
s = Text1.Text
ret = checkDate(s, errMsg)
If Not ret Then
MsgBox errMsg
Else
' ...
End If
En faisant un design comme celui-ci pour CheckDate(), je
garde un découpage clair entre fonctionnel et interface.
Demain je peux me reservir de ma fonction dans un
autre programme sans problème. Ma fonction est indépendante.
Rappel de la règle N°1:
"A chacun son métier, et les vaches seront bien gardées.".
Ca s'applique aussi à la programmation : une fonction doit faire
son boulot, rien de moins et rien de plus.
Ce genre de chose est la base de la programmation structurée.
Il a toujours plein de mauvaises =>excuses<= pour faire un
mauvais design, mais jamais de vraies =>raisons<= :-)
J'aurais préféré utiliser la procédure qu'une fonction car je n'aurais eu à mettre qu'une ligne d'appel par zone à contrôler alors qu'avec la fonction ça fait quand même un petit bloc par zone.
Mauvais argument. Du code un poil plus long mais clair et modulaire est **toujours** un gain de temps et un gage de qualité.
Mais, d'une part je n'arrive pas à faire fonctionner correctement l'appel à la procédure (en fait le cancel ne fait rien) Je peux toujours réinitialiser le champ dans la procédure mais je ne vois pas comment lui redonner le focus.
C'est certainement parce que tu tombes dans le piège classique des arguments byval/byref dans les procédures. C'est un grand classique, tu trouveras la solution ici: http://faq.vb.free.fr/index.php?question#
Pour ce qui est de mélanger les MsgBox avec les instructions de vérification, j'en ai besoin car selon l'erreur le message n'est pas le même.
Mauvais argument. Rien n'interdit à ta fonction d'etre intelligente et de retourner une variable qui contient la raison de l'erreur:
Par exemple:
Private Function checkDate(ByVal aDate As String, ByRef errMsg As String) As Boolean
If IsDate(aDate) Then If CDate(aDate) > CDate(Now) Then errMsg = "Date postérieure à la date du jour" checkDate = False Else checkDate = True End If Else errMsg = "Format de date non valide" checkDate = False End If End Function
puis:
Dim s As String Dim errMsg As String
s = Text1.Text ret = checkDate(s, errMsg) If Not ret Then MsgBox errMsg Else ' ... End If
En faisant un design comme celui-ci pour CheckDate(), je garde un découpage clair entre fonctionnel et interface. Demain je peux me reservir de ma fonction dans un autre programme sans problème. Ma fonction est indépendante.
Rappel de la règle N°1: "A chacun son métier, et les vaches seront bien gardées.".
Ca s'applique aussi à la programmation : une fonction doit faire son boulot, rien de moins et rien de plus.
Ce genre de chose est la base de la programmation structurée. Il a toujours plein de mauvaises =>excuses<= pour faire un mauvais design, mais jamais de vraies =>raisons<= :-)
Pour moi il ne s'agit pas du tout d'une optimisation mais de l'utilisation au mieux des booléens. Chaque fois que je peux j'évite les écritures <variable booléenne>=(Vraie|Fausse) sauf pour les initialisations où je n'hésite jamais à écrire <variable booléenne>úlse même si c'est parfaitement inutile car elles sont par défaut initialisées à false. Ainsi je n'utilise jamais if <condition> then <booléen>=true (ou false d'ailleurs)
Ma remarque provient aussi du fait que je n'ai pas très bien compris pourquoi une erreur d'entrée de date se traduit par un cancel au lieu d'un traitement d'erreur.
"jean-marc" a écrit dans le message de news: 472889ef$0$29259$
"Patrice Henrio" wrote in message news:
Jean Marc ne crois-tu pas que l'écriture suivante permettrait une affectation de cancel plus dans l'esprit du traitement ?
Private Sub Text1_Validate(Cancel As Boolean) Dim s As String 'Dim ret As Boolean s = Text1.Text cancel = not(checkDate(s)) If cancel Then ' probleme, date invalide MsgBox "Date Invalide" Text1.Text = "" Else ' tout va bien, la date est "valide" Text1.Text = Format$(s, "dd/mm/yyyy") End If
Hello Patrice,
Si, ca le ferait, et même très bien :-))
Je trouve ça moins lisible, mais c'est purement personnel :-)
Il faut dire que je suis conditionné à écrire du code qui va être lu et potentiellement modifié par beaucoup de personnes, ce qui fait que j'écris automatiquement du code le plus lisible et facile à débugger possible.
Je n'hésite donc pas à multiplier les variables et à écrire de façon vraiment séquentiel, afin que le code puisse être auto-documenté. Je me dis aussi que c'est le boulot du compilateur de faire ce genre d'optimisations :-)
Pour moi il ne s'agit pas du tout d'une optimisation mais de l'utilisation
au mieux des booléens.
Chaque fois que je peux j'évite les écritures <variable
booléenne>=(Vraie|Fausse) sauf pour les initialisations où je n'hésite
jamais à écrire <variable booléenne>úlse même si c'est parfaitement
inutile car elles sont par défaut initialisées à false.
Ainsi je n'utilise jamais
if <condition> then <booléen>=true (ou false d'ailleurs)
Ma remarque provient aussi du fait que je n'ai pas très bien compris
pourquoi une erreur d'entrée de date se traduit par un cancel au lieu d'un
traitement d'erreur.
"jean-marc" <jean_marc_n2@yahoo.fr.invalid> a écrit dans le message de news:
472889ef$0$29259$ba620e4c@news.skynet.be...
"Patrice Henrio" <patrice.henrio@laposte.net> wrote in message
news:eHOkZM8GIHA.280@TK2MSFTNGP03.phx.gbl...
Jean Marc ne crois-tu pas que l'écriture suivante permettrait une
affectation de cancel plus dans l'esprit du traitement ?
Private Sub Text1_Validate(Cancel As Boolean)
Dim s As String
'Dim ret As Boolean
s = Text1.Text
cancel = not(checkDate(s))
If cancel Then
' probleme, date invalide
MsgBox "Date Invalide"
Text1.Text = ""
Else
' tout va bien, la date est "valide"
Text1.Text = Format$(s, "dd/mm/yyyy")
End If
Hello Patrice,
Si, ca le ferait, et même très bien :-))
Je trouve ça moins lisible, mais c'est purement personnel :-)
Il faut dire que je suis conditionné à écrire du code
qui va être lu et potentiellement modifié par beaucoup
de personnes, ce qui fait que j'écris automatiquement du
code le plus lisible et facile à débugger possible.
Je n'hésite donc pas à multiplier les variables et à écrire
de façon vraiment séquentiel, afin que le code puisse être
auto-documenté. Je me dis aussi que c'est le boulot du
compilateur de faire ce genre d'optimisations :-)
Pour moi il ne s'agit pas du tout d'une optimisation mais de l'utilisation au mieux des booléens. Chaque fois que je peux j'évite les écritures <variable booléenne>=(Vraie|Fausse) sauf pour les initialisations où je n'hésite jamais à écrire <variable booléenne>úlse même si c'est parfaitement inutile car elles sont par défaut initialisées à false. Ainsi je n'utilise jamais if <condition> then <booléen>=true (ou false d'ailleurs)
Ma remarque provient aussi du fait que je n'ai pas très bien compris pourquoi une erreur d'entrée de date se traduit par un cancel au lieu d'un traitement d'erreur.
"jean-marc" a écrit dans le message de news: 472889ef$0$29259$
"Patrice Henrio" wrote in message news:
Jean Marc ne crois-tu pas que l'écriture suivante permettrait une affectation de cancel plus dans l'esprit du traitement ?
Private Sub Text1_Validate(Cancel As Boolean) Dim s As String 'Dim ret As Boolean s = Text1.Text cancel = not(checkDate(s)) If cancel Then ' probleme, date invalide MsgBox "Date Invalide" Text1.Text = "" Else ' tout va bien, la date est "valide" Text1.Text = Format$(s, "dd/mm/yyyy") End If
Hello Patrice,
Si, ca le ferait, et même très bien :-))
Je trouve ça moins lisible, mais c'est purement personnel :-)
Il faut dire que je suis conditionné à écrire du code qui va être lu et potentiellement modifié par beaucoup de personnes, ce qui fait que j'écris automatiquement du code le plus lisible et facile à débugger possible.
Je n'hésite donc pas à multiplier les variables et à écrire de façon vraiment séquentiel, afin que le code puisse être auto-documenté. Je me dis aussi que c'est le boulot du compilateur de faire ce genre d'optimisations :-)
"jean-marc" wrote in message news:4728a891$0$22321$
"jerome" wrote in message news: > > J'aurais préféré utiliser la procédure qu'une fonction car je n'aurais
eu
> à > mettre qu'une ligne d'appel par zone à contrôler alors qu'avec la
fonction
> ça fait quand même un petit bloc par zone.
Mauvais argument. Du code un poil plus long mais clair et modulaire est **toujours** un gain de temps et un gage de qualité.
> Mais, d'une part je n'arrive pas à faire fonctionner correctement
l'appel
> à > la procédure (en fait le cancel ne fait rien) Je peux toujours > réinitialiser > le champ dans la procédure mais je ne vois pas comment lui redonner le > focus.
C'est certainement parce que tu tombes dans le piège classique des arguments byval/byref dans les procédures. C'est un grand classique, tu trouveras la solution ici: http://faq.vb.free.fr/index.php?question#
> Pour ce qui est de mélanger les MsgBox avec les instructions de > vérification, j'en ai besoin car selon l'erreur le message n'est pas le > même.
Mauvais argument. Rien n'interdit à ta fonction d'etre intelligente et de retourner une variable qui contient la raison de l'erreur:
Par exemple:
Private Function checkDate(ByVal aDate As String, ByRef errMsg As String)
As
Boolean
If IsDate(aDate) Then If CDate(aDate) > CDate(Now) Then errMsg = "Date postérieure à la date du jour" checkDate = False Else checkDate = True End If Else errMsg = "Format de date non valide" checkDate = False End If End Function
puis:
Dim s As String Dim errMsg As String
s = Text1.Text ret = checkDate(s, errMsg) If Not ret Then MsgBox errMsg Else ' ... End If
En faisant un design comme celui-ci pour CheckDate(), je garde un découpage clair entre fonctionnel et interface. Demain je peux me reservir de ma fonction dans un autre programme sans problème. Ma fonction est indépendante.
Rappel de la règle N°1: "A chacun son métier, et les vaches seront bien gardées.".
Ca s'applique aussi à la programmation : une fonction doit faire son boulot, rien de moins et rien de plus.
Ce genre de chose est la base de la programmation structurée. Il a toujours plein de mauvaises =>excuses<= pour faire un mauvais design, mais jamais de vraies =>raisons<= :-)
"jean-marc" <jean_marc_n2@yahoo.fr.invalid> wrote in message
news:4728a891$0$22321$ba620e4c@news.skynet.be...
"jerome" <jerome@hh.fr> wrote in message
news:utY8mU9GIHA.2328@TK2MSFTNGP03.phx.gbl...
>
> J'aurais préféré utiliser la procédure qu'une fonction car je n'aurais
eu
> à
> mettre qu'une ligne d'appel par zone à contrôler alors qu'avec la
fonction
> ça fait quand même un petit bloc par zone.
Mauvais argument. Du code un poil plus long mais clair
et modulaire est **toujours** un gain de temps et un
gage de qualité.
> Mais, d'une part je n'arrive pas à faire fonctionner correctement
l'appel
> à
> la procédure (en fait le cancel ne fait rien) Je peux toujours
> réinitialiser
> le champ dans la procédure mais je ne vois pas comment lui redonner le
> focus.
C'est certainement parce que tu tombes dans le piège classique
des arguments byval/byref dans les procédures. C'est un grand
classique, tu trouveras la solution ici:
http://faq.vb.free.fr/index.php?question#
> Pour ce qui est de mélanger les MsgBox avec les instructions de
> vérification, j'en ai besoin car selon l'erreur le message n'est pas le
> même.
Mauvais argument. Rien n'interdit à ta fonction d'etre
intelligente et de retourner une variable qui contient
la raison de l'erreur:
Par exemple:
Private Function checkDate(ByVal aDate As String, ByRef errMsg As String)
As
Boolean
If IsDate(aDate) Then
If CDate(aDate) > CDate(Now) Then
errMsg = "Date postérieure à la date du jour"
checkDate = False
Else
checkDate = True
End If
Else
errMsg = "Format de date non valide"
checkDate = False
End If
End Function
puis:
Dim s As String
Dim errMsg As String
s = Text1.Text
ret = checkDate(s, errMsg)
If Not ret Then
MsgBox errMsg
Else
' ...
End If
En faisant un design comme celui-ci pour CheckDate(), je
garde un découpage clair entre fonctionnel et interface.
Demain je peux me reservir de ma fonction dans un
autre programme sans problème. Ma fonction est indépendante.
Rappel de la règle N°1:
"A chacun son métier, et les vaches seront bien gardées.".
Ca s'applique aussi à la programmation : une fonction doit faire
son boulot, rien de moins et rien de plus.
Ce genre de chose est la base de la programmation structurée.
Il a toujours plein de mauvaises =>excuses<= pour faire un
mauvais design, mais jamais de vraies =>raisons<= :-)
"jean-marc" wrote in message news:4728a891$0$22321$
"jerome" wrote in message news: > > J'aurais préféré utiliser la procédure qu'une fonction car je n'aurais
eu
> à > mettre qu'une ligne d'appel par zone à contrôler alors qu'avec la
fonction
> ça fait quand même un petit bloc par zone.
Mauvais argument. Du code un poil plus long mais clair et modulaire est **toujours** un gain de temps et un gage de qualité.
> Mais, d'une part je n'arrive pas à faire fonctionner correctement
l'appel
> à > la procédure (en fait le cancel ne fait rien) Je peux toujours > réinitialiser > le champ dans la procédure mais je ne vois pas comment lui redonner le > focus.
C'est certainement parce que tu tombes dans le piège classique des arguments byval/byref dans les procédures. C'est un grand classique, tu trouveras la solution ici: http://faq.vb.free.fr/index.php?question#
> Pour ce qui est de mélanger les MsgBox avec les instructions de > vérification, j'en ai besoin car selon l'erreur le message n'est pas le > même.
Mauvais argument. Rien n'interdit à ta fonction d'etre intelligente et de retourner une variable qui contient la raison de l'erreur:
Par exemple:
Private Function checkDate(ByVal aDate As String, ByRef errMsg As String)
As
Boolean
If IsDate(aDate) Then If CDate(aDate) > CDate(Now) Then errMsg = "Date postérieure à la date du jour" checkDate = False Else checkDate = True End If Else errMsg = "Format de date non valide" checkDate = False End If End Function
puis:
Dim s As String Dim errMsg As String
s = Text1.Text ret = checkDate(s, errMsg) If Not ret Then MsgBox errMsg Else ' ... End If
En faisant un design comme celui-ci pour CheckDate(), je garde un découpage clair entre fonctionnel et interface. Demain je peux me reservir de ma fonction dans un autre programme sans problème. Ma fonction est indépendante.
Rappel de la règle N°1: "A chacun son métier, et les vaches seront bien gardées.".
Ca s'applique aussi à la programmation : une fonction doit faire son boulot, rien de moins et rien de plus.
Ce genre de chose est la base de la programmation structurée. Il a toujours plein de mauvaises =>excuses<= pour faire un mauvais design, mais jamais de vraies =>raisons<= :-)
