Discussion :

[byloute]

Bonjour,

Je crée une macro avec plusieurs étapes, le tout entre "Sub Ma_Macro()" et "End Sub"
Comment puis-je sortir de la macro sans exécuter la suite du programme si le formulaire n'existe pas ?
J'ai tenté de mettre un "Exit" après "End If", à priori sans succès.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
Sub Ma_Macro()
 
Dim Formulaire As String
 Formulaire = Dir("D:\Macro\Formulaire.xlsx")
 If Formulaire = "" Then
     MsgBox "Attention, le formulaire n'existe pas. Il est nécessaire pour exécuter la procédure globale", vbCritical
        End If
 
Instructions de la macro
Action1
Action2
etc...
 
End Sub

Merci à tous,

[BENNASR]

bonsoir

Code :

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

1
2
3
4
If Formulaire = "" Then
      MsgBox "Attention, le formulaire n'existe pas. Il est nécessaire pour exécuter la procédure globale", vbCritical
      exit sub
      End If

[patricktoulon]

bonjour BENNARS
en l'occurrence dans cet exemple on peut largement se passer de la sortie brutale(exit sub )

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Sub Ma_Macro()
 
Dim Formulaire As String
 Formulaire = Dir("D:\Macro\Formulaire.xlsx")
 If Formulaire = "" Then
     MsgBox "Attention, le formulaire n'existe pas. Il est nécessaire pour exécuter la procédure globale", vbCritical
        
 else
Instructions de la macro
Action1
Action2
etc...
End If 
End Sub

[Menhir]

Perso, j'utilise plutôt la solution de Bennasr.
Je sais que les puristes du codage vont pousser des hauts cris mais conserver un niveau de structure supplémentaire pour tout le reste de la macro, si je peux éviter, j'évite.
Idem pour les Exit Do et autres Exit For.

Pas très puriste mais pragmatique.

[Patrice740]

Bonjour le Fil

en l'occurrence dans cet exemple on peut largement se passer de la sortie brutale(exit sub )

Je rejoins l'avis de Menhir et je ne vois pas en quoi Exit sub serait plus brutal que End sub !
La différence n'est pas fonctionnelle mais structurelle : le second est nécessaire pour définir (pour le compilateur) la fin de la structure.
Une fois compilée, une sortie reste une sortie.

PS : je ne mets jamais les pieds dans ces magasins de meubles scandinaves avec une seule entrée et une seule sortie à l'autre extrémité, je veux pouvoir sortir quand j'en ai envie.

[Transitoire]

Bonjour, juste pour le fun:

PS : je ne mets jamais les pieds dans ces magasins de meubles scandinaves avec une seule entrée et une seule sortie à l'autre extrémité, je veux pouvoir sortir quand j'en ai envie.

Dans le magasin scandinave comme d'autre il existe des passages, certes pas très visibles, qui permettent d'éviter des secteurs entiers. des sortes "d'Exit Sub"

Cordialement

[Pierre Fauconnier]

Salut.

Je mets ça là, pour illustrer ce qui se passe si vous répondez oui au msgbox...



Il en va de même avec les structures des On Error où l'on voit souvent cette structure de code.

Code :

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

1
2
3
4
5
6
7
8
9
10
Sub Test3()
  On Error GoTo Cath
  Application.EnableEvents = False
  ...
  ...
  Application.EnableEvents = True
  Exit Sub
Catch:
  MsgBox "Une erreur est survenue"
End Sub

Perso, je préfère celle-ci

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Sub Test3()
  On Error GoTo Catch
  Application.EnableEvents = False
  ...
  ...
 
Catch:
  If Err <> 0 Then
    MsgBox "Une erreur est survenue"
    ...
    ...
  End If
  Application.EnableEvents = True
End Sub

Cela dit, dans un code bien structuré, on n'a besoin ni d'Exit Sub ou for ou do, ni d'un IF... en entrée de proc, selon moi. Je coderais différemment ma_macro donnée à l'entame de la discussion pour respecter une architecture de code que je trouve plus cohérente.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Sub Appel()
  If Dir("D:\Macro\Formulaire.xlsx") <> "" Then
    Traitement
  Else
    MsgBox "Attention, le formulaire n'existe pas. Il est nécessaire pour exécuter la procédure globale", vbCritical
  End If
End Sub
 
Sub Traitement()
  ...
  ...
  ...
End Sub

[Philippe Tulliez]

Bonjour Pierre,
Je suis d'accord que dans certaine procédure complexe, la sortie avec End Sub, End Function, etc. peut s'averée inadéquate mais j'avoue que dans ton exemple, tu le fais un peu exprès car dans le code ci-dessous cela renvoie bien True à l'entrée et à la sortie de la procédure

Code :

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

1
2
3
4
5
Private Sub Worksheet_Change(ByVal Target As Range)
  Debug.Print Application.EnableEvents
  TestMsgBox
  Debug.Print Application.EnableEvents
End Sub

Code :

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

1
2
3
4
5
6
7
8
Private Sub TestMsgBox()
  If MsgBox("Modif de cellule", vbYesNo) = vbYes Then
     Application.EnableEvents = False
     Feuil1.Range("A1").Value = "ok"
     Application.EnableEvents = True
     Exit Sub
  End If
End Sub

mais c'est vrai que ce n'est pas l'idéal d'utiliser le End d'un process

[Pierre Fauconnier]

Salut Philippe,

Le code que j'expose est simple, voire simpliste... Il illustre simplement le danger des EXIT dans la mesure où cela t'impose de vérifier deux fois si tu sors proprement. Les Debug.print illustrent justement que la sortie de test2 n'était pas propre à cause de l'exit sub.

[...]

Code :

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

1
2
3
4
5
6
7
8
9
Private Sub TestMsgBox()
  If MsgBox("Modif de cellule", vbYesNo) = vbYes Then
     Application.EnableEvents = False
     Feuil1.Range("A1").Value = "ok"
     Application.EnableEvents = True
     Exit Sub
  End If
 
End Sub

Dans le code que tu donnes, tu remets de suite EnableEvents à True, et il n'y a que cela à remettre avant de sortir, mais dans des cas un peu plus complexes, il y a parfois plus de trucs à remettre correctement après et on ne peut pas toujours n'intercaler qu'une seule ligne entre la mise à False et la remise à True. Et de toute façon, on peut pas selon moi gérer ce genre de modif d'une option de l'appli sans une gestion d'erreur très serrée autour. Si tu observes le code suivant et qu'une erreur survient entre la mise à False et la remise à True dans TestMsgBox, tu auras de toute façon un souci avec la gestion future des événements (ici, pour l'exemple, j'ai verrouillé la cellule A1, mais dans la vraie vie d'un programme, bien plus de choses peuvent arriver...). Et comme tu ne peux pas toujours savoir ce qui va se passer dans ce que tu appelles, tu ne penseras pas forcément à remettre ton EnableEvents à True en sortant de Worksheet_Change...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Private Sub Worksheet_Change(ByVal Target As Range)
  On Error GoTo EndHandler
  Debug.Print Application.EnableEvents
  TestMsgBox
  Debug.Print Application.EnableEvents
 
EndHandler:
  If Err <> 0 Then MsgBox "une erreur est survenue"
  Debug.Print Application.EnableEvents
End Sub
 
Private Sub TestMsgBox()
  If MsgBox("Modif de cellule", vbYesNo) = vbYes Then
     Application.EnableEvents = False
     Feuil1.Range("A1").Value = "ok"
     Application.EnableEvents = True
     Exit Sub
  End If
End Sub

J'essaie personnellement d'être systématique dans mon approche de la programmation (c'est cela que moi j'appelle pragmatisme), et j'ai appris, à mes dépens puis de façon théorique, qu'il était judicieux de n'avoir qu'une sortie de boucle et qu'une sortie de proc/fonction... Je reste donc parfaitement convaincu qu'il ne faut pas utiliser Exit et réfléchir cinq fois plutôt que quatre à l'architecture de son code, car il y a toujours une autre solution que Exit, et y réfléchir amène à trouver une structure plus propre. Après, je ne me bats plus pour cela sur les forums, j'ai donné mes arguments, je n'en changerai pas et ne palabrerai pas sur le sujet,il parait que ça met une mauvaise ambiance. Dans mon boulot, je facture bien cher quand je dois mettre les doigts dans du code farci à l'exit sub. Je dis au client que c'est mauvais, j'argumente et je lui montre qu'avec un code pareil, on s'attend à d'autres chausse-trapes sur lesquels je mets souvent rapidement le doigt. Dans 90% des cas, le client est convaincu, on jette le tout à la poubelle et je recommence à zéro. Dans les 10% qui refusent qu'on jette le truc, je vais voir ailleurs et le client se démerde avec son code poubelle. (poubelle, c'est juste mon jugement, ce n'est pas LA vérité universelle).