Boo - Excel Automation, difficulté à sélectionner les plages

Question

J'enquête sur Boo et pensé que ce serait un exercice utile pour essayer de convertir un couple de scripts VB vénérables qui automatisent Excel (2007, en l'occurrence). Beaucoup de choses semblent traduire très facilement, mais je vais avoir une énorme quantité de plages de sélection de trouble -. Chaque fois que je tente d'obtenir ou de les mettre, je reçois un membre TargetInvocationException pas trouvé

Voici un exemple (réduire) J'ai couru dans booish:

def CreateInstance(progid):
    type = System.Type.GetTypeFromProgID(progid)    
    return type()   

xl as duck = CreateInstance("Excel.Application")
xl.Visible = true
xl.Workbooks.Add

sht as duck = xl.ActiveSheet
#Next line throws exception
rng as duck = sht.Range("A1")

Certaines choses fonctionnent bien, comme définissant la propriété Nom de la feuille et ainsi de suite, mais comment puis-je travailler avec des gammes? Y a-t-il des méthodes spéciales que VB cache que je dois appeler, et si oui, comment pourrais-je faire pour trouver les sortir?

Cheers,

Lenny.

Answer 1

Range est en fait une propriété, et il est une propriété peu particulière en ce qu'elle fonctionne comme un indexeur, ce qui signifie qu'il a array- ou sémantique comme dictionnaire. Dans la plupart des langues, cela signifie que vous devez accéder à sht.Range["A1"]. C'est le sucre syntaxique, et vraiment c'est accessible comme tout autre méthode, à savoir:

sht.get_Range("A1",System.Reflection.Missing.Method)

Je tentais d'utiliser Boo, Ruby et IronRuby répéter votre code, utilisant à la fois le style de sucre syntaxique et l'appel de méthode explicite. En IronRuby, je peux le faire fonctionner parfaitement, mais uniquement dans l'interpréteur 32 bits . Dans Ruby régulière, qui est une application 32 bits sur ma configuration, il a également travaillé très bien. Dans l'interpréteur 64 bits, la propriété Range n'a jamais été résolu correctement.

Alors, qui m'a conduit à penser que le Boo Interactive Shell était en cours d'exécution en mode 64 bits et que Interop ne parvenait pas à cause de cela. Malheureusement, les mêmes problèmes après avoir reproduit mes binaires locaux de Boo pour fonctionner en mode 32 bits en utilisant CORFLAGS.exe, donc je ne pense pas que ce soit la vraie question.

Qu'est-ce que le travail, cependant, était d'importer explicitement Excel Dotnet Interop Library, ainsi que les services Interop espaces de noms, comme ceci:

import Microsoft.Office.Interop.Excel
import System.Runtime.InteropServices

xl_type=typeof(Application).GetCustomAttributes(typeof(CoClassAttribute),true)[0].CoClass
xl=xl_type()
xl.Visible=true
xl.Workbooks.Add

Alors:

xl.Range["A1","A2"].Value=12
xl.Range["A1",System.Type.Missing].Value="Alpha"
(xl.ActiveSheet as Worksheet).Range["A1","A2"].Value2='Whatever'

Tous ces travaux, mais ils ont besoin essentiellement vous donner le « Scriptiness » vous êtes habitué de la liaison tardive (qui est ce que votre frappe de canard fait).

Une différence de VB / VBScript qui est vrai pour la plupart des langues (autres que C # 4.0) est que, généralement, les paramètres facultatifs ne sont pas gérés de manière transparente, de sorte que vous auriez besoin de regarder l'API plus attentivement lorsque vous traitez avec des méthodes que les supports des paramètres optionnels (en les remplaçant par System.Type.Missing ou l'équivalent System.Reflection). Vous trouveriez cela à travers les documents Interop Excel, vous pouvez probablement bien utiliser la réflexion pour identifier les paramètres marqués en option si vous trouvez que plus facile que de regarder vers le haut.

Parce que Ruby a une solution raisonnable pour la liaison tardive de ces objets, je pense qu'il ya un élément manquant (ou bug) dans les scénarios COM Interop à Boo.

Sous la direction d'ajouter: Sam Ng écrit au sujet du soutien de la propriété indexées dans C # 4.0 ; les problèmes décrits dans son poste appliquent probablement Boo, aussi bien.