Parfois, Excel donne simplement un message du type «Excel a cessé de fonctionner. Nous sommes désolés pour tout inconvénient. "
Lorsque vous recevez un tel message, vous pouvez appuyer sur Ctrl + alt = "" + Supprimer et ouvrir à nouveau le classeur (avec un peu de chance, après avoir enregistré tout le travail que vous avez fait!), Voulant parcourir le code pour trouver l'instruction incriminée. Lorsque vous parcourez le code en une seule étape, tout peut fonctionner correctement, mais lorsque vous l'exécutez à pleine vitesse, il peut à nouveau se bloquer. Comment pouvez-vous trouver la déclaration incriminée?
Vous pouvez écrire une simple ligne de code entre chaque ligne de code qui pourrait être le coupable. Ainsi, le code VBA peut à l'origine ressembler à ceci:
Sub UICreation() Dim x As String On Error Resume Next x = Sheets("Scenario").Name If Err.Number 0 Then MsgBox "Current workbook needs to have a Scenario sheet!", vbCritical Exit Sub End If ActiveWorkbook.Unprotect WorkbookPassword Err.Clear ActiveWorkbook.Unprotect SheetPassword If Err.Number 0 Then MsgBox "Workbook cannot be unprotected by the macro.", vbCritical Exit Sub End If Application.OnTime Now, "More" ThisWorkbook.Sheets("FastPricer").Copy Before:=ActiveWorkbook.Sheets(1) End Sub
Cette procédure, en fait, ne plante pas, mais elle illustre ce que vous pouvez faire si vous constatez que le code plante lorsqu'il est exécuté à pleine vitesse, mais pas lorsque vous le parcourez.
Vous changez le code ci-dessus en ceci, avec des instructions insérées Bug 1, Bug 2, etc.:
Sub UICreation() Dim x As String On Error Resume Next Bug 1 x = Sheets("Scenario").Name Bug 2 If Err.Number 0 Then MsgBox "Current workbook needs to have a Scenario sheet!", vbCritical Exit Sub End If Bug 3 ActiveWorkbook.Unprotect WorkbookPassword Err.Clear Bug 4 ActiveWorkbook.Unprotect SheetPassword If Err.Number 0 Then MsgBox "Workbook cannot be unprotected by the macro.", vbCritical Exit Sub End If Bug 5 Application.OnTime Now, "More" Bug 6 ThisWorkbook.Sheets("FastPricer").Copy Before:=ActiveWorkbook.Sheets(1) End Sub
Voici la procédure de bogue:
Sub Bug(num As Integer) SaveSetting "EOTB2", "EOTB2", "EOTB2", num End Sub
Cette procédure enregistre une valeur dans le registre. La syntaxe de SaveSetting est:

Pour les trois premiers paramètres, disons que vous utilisez EOTB2 (pour Excel Outside the Box 2) - une sélection aléatoire. Vous pouvez à la place utiliser SaveSetting "X", "X", "X", num. Si vous l'utilisez beaucoup, vous pouvez profiter des trois niveaux AppName, Section et Key. De cette façon, si vous avez de nombreuses sections dans AppName, vous pouvez nettoyer le registre pour tous vos paramètres en utilisant le simple DeleteSetting "EOTB2" (ou tout ce que vous définissez pour AppName), et toutes les sections et clés seront également supprimées.
Maintenant, vous exécutez la procédure à pleine vitesse et elle se bloque. Donc, vous redémarrez Excel, accédez au VBE, ouvrez la fenêtre Exécution (en appuyant sur Ctrl + G) et tapez ceci:
? GetSetting(“EOTB2”,”EOTB2”,”EOTB2”)
Si cette procédure renvoie 4, par exemple, elle s'est plantée quelque temps après le bogue 4. Il est peu probable que la section If / End If soit le coupable; il s'agissait probablement d'ActiveWorkbook.Unprotect SheetPassword. (N'oubliez pas que ce n'est qu'un exemple, pas ce qui s'est réellement passé.)
Si votre exécution initiale du bogue 1, du bogue 2, etc. montre que la procédure s'est plantée dans une grande section de code après le bogue x, vous pouvez insérer plus d'appels de bogue pour la réduire davantage. Vous faites en quelque sorte une recherche binaire dans une longue procédure pour trouver le coupable.

Cet article invité provient d'Excel MVP Bob Umlas. Il est tiré du livre More Excel Outside the Box. Pour voir les autres sujets du livre, cliquez ici.