Boo - automazione di Excel, problemi a selezionare gamme

Question

Sto indagando Boo e ho pensato che sarebbe stato un esercizio utile per provare la conversione di un paio di script VB venerabili che consentono di automatizzare Excel (2007, in questo caso). Un sacco di cose sembrano a tradurre molto facilmente, ma sto avendo una quantità enorme di problemi a selezionare gamme -. Ogni volta che provo per ottenere o impostare li ottengo un membro TargetInvocationException non trovato

Ecco un (ridurre) esempio ho eseguito in 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")

Certe cose funzionano bene, come ad esempio l'impostazione della proprietà Nome del foglio e così via, ma come faccio a lavorare con gamme? Ci sono alcuni metodi speciali che VB nasconde che avevo bisogno di chiamare, e se sì, come dovrei fare per trovare quelli fuori?

Saluti,

Lenny.

Answer 1

Gamma è in realtà una proprietà, ed è una proprietà un po 'speciale, in quanto funziona come un indicizzatore, che significa che ha una semantica nell'edificio- o dizionario-like. Nella maggior parte delle lingue, che significa che ci si accede sht.Range["A1"]. Cioè zucchero sintattico, e in realtà è accessibile come qualsiasi altro metodo, vale a dire:

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

Ho cercato di usare Boo, Ruby e IronRuby di ripetere il codice, utilizzando sia lo stile di zucchero sintattico e il metodo di chiamata esplicita. In IronRuby, posso farlo funzionare senza problemi, ma solo l'interprete a 32 bit . Nel regolare Ruby, che è un'applicazione a 32 bit sulla mia configurazione, anche funzionato bene. Nel interprete a 64 bit, la proprietà Range non è mai stato risolto correttamente.

In modo che mi ha portato a sospettare che la Boo Interactive Shell era in esecuzione in modalità a 64 bit e che interoperabilità stava venendo a mancare a causa di questo. Purtroppo, gli stessi problemi riprodotti dopo aver impostato i miei binari Boo locali per l'esecuzione in modalità a 32 bit utilizzando CORFLAGS.exe, quindi non credo che sia il vero problema.

Che cosa ha fatto il lavoro, però, è stato quello di importare in modo esplicito il Dotnet Interop Biblioteca Excel, nonché i servizi di namespace Interop, in questo modo:

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

Quindi:

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

Tutti questi lavori, ma sostanzialmente richiedono di rinunciare al "Scriptiness" a cui siete abituati da late-binding (che è ciò che la digitazione anatra sta facendo).

Una differenza da VB / VBScript che è vero per la maggior parte delle lingue (diversa da C # 4.0) è che, in generale, i parametri opzionali non sono gestite in modo trasparente, in modo avresti bisogno di guardare l'API più con attenzione quando avete a che fare con i metodi che supportano parametri facoltativi (sostituendoli con System.Type.Missing o System.Reflection equivalente). Che si può trovare questo attraverso la documentazione di interoperabilità di Excel, anche se probabilmente si può utilizzare la riflessione per identificare i parametri contrassegnati come optional se si scopre che più facile che guardare in su.

A causa Ruby ha una soluzione ragionevole per la fine del legame questi oggetti, ho il sospetto che ci sia una caratteristica mancante (o bug) in scenari di interoperabilità COM a Boo.

A cura di aggiungere: Sam Ng scrive di supporto Alloggio referenziato in C # 4.0 ; i problemi descritti nel suo post probabilmente si applicano a Boo, pure.