2008-11-21 19 views
3

Je suis (malheureusement) en train de développer une application dans Excel 2000 VBA. Je crois que j'ai découvert que toute erreur soulevée dans une propriété de classe personnalisée, une fonction ou des sous-déboguages ​​comme si l'erreur avait été déclenchée au point dans le code VBA où la propriété est appelée. En d'autres termes, le débogueur VBE ne m'amène pas au point de la propriété Class où l'erreur s'est produite, mais à la place où la propriété a été entrée (depuis un sous-module ou une fonction, par exemple). le code VBA OO Excel 2000 le plus superficiel puisque je dois parcourir chaque méthode Class-by-line pour découvrir les instructions provoquant une erreur.Erreurs déclenchées dans le débogage de classe comme si elles étaient déclenchées par la propriété

Ai-je raté quelque chose ou est-ce un bug connu dans Excel 2000? Cela a-t-il été corrigé en 2003 ou 2007?

code Exemple:

''''''''''''''' 
'In Module1: 

Public Sub TestSub1() 
    Dim testClass As Class1 
    Dim testVariant As Variant 
    Set testClass = New Class1 
    testVariant = testClass.Property1 'Debugger takes me here... 
End Sub 

'''''''''''''' 
' In Class1 

Property Get Property1() As Variant 
    Err.Raise 666, , "Excel 2000 VBA Sux!" 'But error is actually thrown here. 
End Property 

Répondre

4

Pour Office 2003, vous obtiendrez ce comportement lorsque le débogueur est configuré pour interrompre les erreurs non gérées (la configuration par défaut).

Si vous voulez que la ligne Err.Raise soit interrompue, vous devez la configurer pour interrompre toutes les erreurs (Outils/Options/Général/Interception des erreurs/Interruption de toutes les erreurs).

Je crois que c'est la même chose pour Office 2000 mais que vous n'avez pas de copie à vérifier.

+0

Merci! En fait, des trois options (pause sur ÉVASION en classe, et la coupure sur les erreurs non prises en charge) Rupture de classe est ce que je pense que je cherchais. –

0

Cette « fonctionnalité » est le même dans Excel 2003 et je serais surpris si c'est différent en 2007.

+0

Cette « particularité » ressemble plus à un stratagème pour encourager les achats Visual Studio. Le soupir. Merci! –

+0

Je pense que Microsoft a délibérément négligé VBA depuis environ 10 ans, en faveur de .Net, etc. Ils ne reçoivent pas seulement la valeur que VBA ajoute dans les affaires courantes. – dbb

+0

C'est la même fonctionnalité. C'est le même code en fait. A été pendant environ une décennie maintenant. Il semble qu'il y ait trop de stabilité. –

0

La même chose est toujours vrai dans Excel 2010 - c'est où j'ai rencontré ce comportement.

Pour citer Chip Pearson's site:

Il n'y a absolument aucune raison d'utiliser un piégeage d'erreur autre paramètre que Break In Module de classe.

Sa description de la différence entre les modes d'erreur:

Lorsque vous testez votre code et en cours d'exécution, vous disposez de trois modes de piégeage d'erreur. Le premier est Break On All Errors. Cela provoquera l'ouverture du débogueur si une erreur se produit, indépendamment de la gestion des erreurs que vous pourriez avoir dans le code. La deuxième option est Break On Unhandled Errors. Cela provoquera l'ouverture du débogueur si l'erreur n'est pas gérée par une directive On Error existante. C'est l'option la plus utilisée et le paramètre par défaut. La troisième option, Break In Class Module est la plus importante et la moins utilisée. Ce n'est pas le mode de recouvrement des erreurs par défaut, vous devez donc le configurer manuellement. Le module Break In Class est le plus important car il provoque le débogage du débogueur sur la ligne de code au sein d'un module objet qui cause réellement le problème. Le paramètre Break In Class Module se trouve dans la boîte de dialogue Options accessible dans le menu Outils. C'est dans l'onglet Général de la boîte de dialogue Options, comme indiqué ci-dessous.

+0

Etes-vous sûr qu'il n'y a pas raison? Pour autant que je sais avec le réglage suggéré 'Err.Raise' ne peut pas être utilisé dans une classe. – stenci