Hello boyz



Mon instruction "On error Go To", prévue pour l'erreur d'une " selection.Find(what:=.......)
ne marche qu'une fois.

Elle est à l'intérieur d'une boucle For NExt. 
Le On Error est placé juste avant la recherche, et ça ne marche que pour la première erreur rencontrée, dès que la bouvle a fait un tour, le Goto ne marche plus.
 
ca vous dis qqch?

Une fois la première erreur rencontrée, l'execution du code est passée au gestionnaire d'erreur et celui-ci est désactivé jusqu'a la fin de la gestion de l'erreur (généralement automatique à la sortie de la procédure). Pendant ce temps là, les erreurs ne sont plus gérées

Si après une première erreur, tu continue l'execution de ton code normal, cette execution sera considérée comme étant le traitement de l'erreur.

Donc après avoir traiter l'erreur, pour pouvoir continuer à executer le code normalement sans sortir de la procédure, il faut passer à terminer la gestion d'erreur, pour relancer le gestionnaire.
--> Err.Clear

---- Sevyc64  (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #

ta mis "exit sub" avant la gestion de ton exeption? on error MY_EXCEPTION instruction exit sub MY_EXCEPTION : traitement de l'exeption end sub montre nous ton code pour plus de precision

L'instruction "Err.Clear" est à mon avis ce qui réponds à ma question. Merci bien
Mais je n'arrive pas pas à la faire marcher :
J'ai essayer de placer le err.clear au début de la boucle, a la fin, juste après l'instruction de Goto (ici c'etait Goto copie, donc juste après le Goto...)

Et voila le code pour kazer

 For i = 2 To NbLIgnes
  Err.Clear
 If Cells(i, 3) Like "*Somme*" Then
 Cells(i + 1, 2).Select
   
    isin = ActiveCell
    Windows("POS T0.xls").Activate
    Range("B:B").Select
    [B2].Activate
   
    On Error GoTo copie
    ligneisin = Selection.Find(what:=isin, after:=ActiveCell).Row()
    Rows(ligneisin).Copy
copie:
  
    Windows("MVT 1.xls").Activate
   
    Rows(i + 1).Select
    Selection.Insert shift:=xlDown
     Selection.End(xlToLeft).Select

(err.clear)

end if
next i

le Err clear ne sert ici rigoureusement à rien puisque, dans ta boucle For to tu repasses par un On Error (lequel, conformément à VB, réinitialise automatiquement err à 0

Voilà ce qu'explique VB :

"The Err object's properties are reset to zero or zero-length strings ("") after any form of the Resume or On Error statement and after an Exit Sub, Exit Function, or Exit Property statement within an error-handling routine. The Clear method can be used to explicitly reset Err".

Explique nous avec des mots simples ce que tu cherches exactement à faire (commente ton code tel que tu l'as écrit) et nous verrons ensemble quelle est la meilleure façon de s'y prendre.

Salut,

il faut gérer avec le numéro de l'erreur.


    On Error Resume Next

For i = 2 To NbLIgnes
    If Cells(i, 3) Like "*Somme*" Then
        Cells(i + 1, 2).Select
        isin = ActiveCell

        Windows("POS T0.xls").Activate

        Range("B:B").Select
        [B2].Activate
    
        If Not Err.Number = XXXXThen
'       remplace XXXX par le bon numéro d'erreur
            ligneisin = Selection.Find(what:=isin, after:=ActiveCell).Row()
            Rows(ligneisin).Copy
        End If

        Windows("MVT 1.xls").Activate
    
        Rows(i + 1).Select
        Selection.Insert shift:=xlDown
        Selection.End(xlToLeft).Select
    End If
Next i

On Error GoTo 0
~Mortalino~


@++

---

Heu ... Au risque de passer pour un empêcheur de tourner en rond, oserais-je dire que l'utilisation d'un "On error goto" en vba, vb6 (ou antérieur) ou d'un "Try ... Catch" en vb.2005 n'est qu'un pis-aller ? Et un inutile bouffeur de resources ?
Oserais-je affirmer que dans 99% des cas, il suffit d'être rigoureux dans le choix des variables, le contrôle des saisies, ... en fait dans la maîtrise de son propre prog ? Peut-être même que le 1% qui reste peut être maîtrisé aussi d'ailleurs.
Personnellement, dans mes progs, je contrôle toutes les entrées et sorties et n'ai jamais eu à utiliser les "on error" en vba ou vb6 ni les "try ... catch" en vb.2005 (sauf en phase de test par fainéantise).

A force de laisser la machine gérer les erreurs, on va finir par remplacer les programmeurs par des machines.

Et pourtant , cher Dolphin Boy, et pourtant !...
Le vieux développeur que je suis te dira que c'est quelquefois justifié, voire incontournable...
Un exemple ?
OK :
Décider de l'utilisation de la première police de caractères disponible sur un PC client parmi une liste de polices possibles, et dans un ordre préférentiel déterminé, sans faire une multitude de tests inutiles d'existence !
et j'en passe, et des meilleures

Dolphin Boy => Tu as surement raison mais la plupart des personnes qui débutent en vb utilisent ce genre de fonction pour connaitre les erreurs qu'il peuvent faire ou, comme tu le dis toi même, "en phase de test par fainéantise" . (sans rancune j'espere)
sinon err.description peut aussi faciliter la compréhension de l'erreur 

Quand je suis là tout va mal  

Je suis entièrement d'accord avec toi Dolphin, pour VB6, moins pour VB.NET.
Le try catch n'a absolument rien à voir avec le on error, c'est même pas comparable.

Cependant, et je suis le premier à ne pas le faire, toutes les routines devraient avoir un gestionnaire d'erreur, car même le code le plus abouti n'est pas à l'abris du bug imprévu. Aucun code ne pourra jamais etre zéro bug, c'est impossible.Et sans gestion de l'erreur, c'est la fermeture brutale de l'appli.
Et lorsque derrière tu as une machine, ça peut etre synonime de casse ou pire de mise en danger de personne.

D'accord avec jmfmarques aussi, parfois c'est incontournable.

---- Sevyc64  (alias Casy) ----

---

# LE PARTAGE EST NOTRE FORCE #