Automatiser Excel à travers le PIA rend VBA aller squiffy

Question

Je n'ai absolument aucune idée de comment commencer à diagnostiquer cela, et je me demandais si quelqu'un avait des suggestions. Je génère une feuille de calcul Excel en appelant des macros à partir d'une application C#, et au cours du processus de génération, il se brise d'une manière ou d'une autre. J'ai une classe VBA contenant tout mon enregistrement/logique de gestion des erreurs, que j'instancier en utilisant un accesseur singleton-esque, ici:

Private mcAppFramework As csys_ApplicationFramework 

Public Function AppFramework() As csys_ApplicationFramework 
    If mcAppFramework Is Nothing Then 
    Set mcAppFramework = New csys_ApplicationFramework 
    Call mcAppFramework.bInitialise 
    End If 

    Set AppFramework = mcAppFramework 
End Function 

Le code ci-dessus fonctionne bien avant que j'ai produit la feuille de calcul mais échoue ensuite. Le problème semble être la ligne suivante;

Set mcAppFramework = New csys_ApplicationFramework 

que je n'ai jamais vu échouer avant. Si j'ajoute une montre à la variable étant assignée ici, le type montre comme csys_ApplicationFramework/wksFoo, où wksFoo est une feuille de calcul aléatoire dans le même classeur. Ce qui semble se produire est que si la variable est de type droit, plutôt que de remplir ce créneau avec une nouvelle instance de ma classe-cadre, il est fait pointer vers une feuille de calcul existant au lieu, l'équivalent de

Set mcAppFramework = wksFoo 

ce qui est une erreur de compilation, comme on pourrait s'y attendre. Encore plus bizarre, si je mets un point d'arrêt sur la ligne fautive, édite la ligne, puis reprend l'exécution, ça marche. Par exemple, je supprime le mot «Nouveau» de la ligne, recule, ressaisit «Nouveau» et recommence l'exécution. Cela résout d'une manière ou d'une autre le classeur et ça marche bien pour toujours, avec le type de la variable dans ma fenêtre de surveillance affichant comme csys_ApplicationFramework/csys_ApplicationFramework comme je m'y attendais.

Cela implique que la manipulation du classeur via l'assembly PIA le brise d'une manière ou d'une autre. Tout ce que je fais dans le PIA est l'ouverture du classeur, l'appel de plusieurs macros en utilisant Excel.Application.Run(), et en l'enregistrant à nouveau. Je peux poster quelques détails supplémentaires si quelqu'un pense que c'est pertinent.

Je ne sais pas comment VBA crée des objets dans les coulisses ou comment déboguer cela. Je ne sais pas non plus comment la façon dont le code s'exécute peut changer sans que le code lui-même ne change.

Comme mentionné précédemment, VBA est franchement un peu carré sur moi ... Des pensées?

Answer 1

Si vous regardez dans le gestionnaire de tâches, y a-t-il des instances de Excel en cours d'exécution? Juste curieux de savoir si c'est créer un objet Excel et ne pas en disposer correctement.

Answer 2

Je suggère que d'une façon ou d'une autre les PIA ne fonctionnent pas correctement. Je vous recommande de les désinscrire, en supprimant toutes les instances de votre PC, puis en les régénérant.

Bien sûr, ce n'est pas l'explication rationnelle que je voudrais donner, mais il semble que parfois COM ne veut tout simplement pas se comporter. J'aimerais savoir ce qui se passe vraiment quand les choses se décomposent comme ça, mais la seule chose que j'ai jamais eu l'air de travailler, c'est de nombreux coups dans l'obscurité, suivis par une tentative de retrofit une explication rationnelle une fois que le refus étrange de travailler disparaît .

Désolé pour l'absence d'une « vraie » réponse