VBA prend une mauvaise branche à IF-statement - Bogue du compilateur sévère?

Public Function Falsee(oClass As cClass) As Boolean
    Set poClass = oClass
    Falsee = False
End Function

(La première instruction si est omise par souci de concision.) Le code est exécuté comme prévu, il est donc crucial que la fonction soit appelée directement dans la condition pour le si Em> instruction (pas quelque chose qui devrait généralement faire une différence).

Et le prochain indice intéressant est le suivant (Supposons que nous utilisons à nouveau le sous-code buggy avec si false (oclass.clone) puis ): Si nous supprimons ce qui suit de notre module de classe:

Private Sub Class_Terminate()
End Sub

L'instruction Si fonctionne comme prévu et rien n'est imprimé! Donc, en quelque sorte, l'événement de résiliation en cours d'exécution lors de l'évaluation de l'IF-Statement gâche les choses, mais le sous-marin class_termiate () ne contient même aucun code! C'est la prochaine chose qui ne devrait pas faire de différence, mais le fait!

Cette idée est en outre soutenue par le fait, que lorsque nous déclarons une variable publique dans le module en ajoutant Public Poclass comme CClass en haut et réécrivez le code de fonction à:

Sub CompilerBug()
    Dim oClass As cClass
    Set oClass = New cClass

    Dim bFalse As Boolean
    bFalse = Falsee(oClass.Clone)

    If bFalse Then
        Debug.Print "This doesn't print, as it shouldn't."
    End If
End Sub

Maintenant, l'événement de terminaison ne se fait pas appelé lors de l'exécution de la mise en place, car l'instance de La classe ne sort pas de portée lors de l'exécution de la staté IF et, par conséquent, la statement IF évalue correctement - la ligne ne s'imprime pas.

De toute évidence, le terminaison Être exécuté lors de l'évaluation de la déclaration IF ne peut pas être toute l'histoire, car cela se produit tout le temps. Cela semble également avoir quelque chose à voir avec la portée de l'objet qui est terminé et la façon dont le paramètre est transmis à la fonction. Par exemple, les éléments suivants pas produisent le même comportement:

Code du module:

Public Function Clone() As cClass
    Dim oClass As cClass
    Set oClass = New cClass
    Set Clone = oClass
End Function

Private Sub Class_Terminate()
End Sub

Et dans le module de classe:

Sub CompilerBug()
    Dim oClass As cClass
    Set oClass = New cClass

    If False Then
        Debug.Print "This doesn't print, as it shouldn't."
    End If

    If Falsee(oClass.Clone) Then
        Debug.Print "This does print, although it shouldn't!"
    End If
End Sub

Public Function Falsee(oClass As cClass) As Boolean
    Falsee = False
End Function

Pour tout résumer, le comportement se produit lorsque:

une méthode d'une classe renvoie une instance de la même chose classe, et cette méthode est appelée à l'intérieur de l'état d'une stades IF, comme argument pour une fonction, et cette instance de la classe (qui a été créée par la méthode) sort ensuite de la portée à l'intérieur de cette fonction et de l'événement terminant de La classe est appelée (et existe comme code). Dans ce cas, l'instruction IF est entrée, quelle que dans ce cas? L'un de mon code est-il censé produire un comportement non défini ou est-ce en fait un bug? Y a-t-il d'autres cas où les stades si ne fonctionnent pas de la manière attendue? Qu'est-ce qui cause exactement ce bug?

Le problème ne semble pas exister dans la version 32 bits d'Excel.