Boo - Excel Automation, faixas selecionando problemas

Question

Estou investigando Boo e pensei que seria um exercício útil para tentar converter um par de Scripts VB veneráveis ??que automatizam Excel (2007, neste caso). Um monte de coisas parecem traduzir muito facilmente, no entanto estou tendo uma enorme quantidade de faixas selecionando problemas -. Sempre que tento obter ou definir-los eu recebo uma TargetInvocationException membro não encontrado

Aqui está um (corte baixo) exemplo Já corri em 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")

certas coisas funcionam bem, como definir a propriedade Nome da folha e assim por diante, mas como faço para trabalhar com faixas? Existem alguns métodos especiais que os couros VB que eu preciso chamar, e se assim como eu iria sobre encontrar aqueles fora?

Cheers,

Lenny.

Answer 1

Gama é realmente uma propriedade, e é uma propriedade pouco especial em que ele funciona como um indexador, o que significa que ele tem array- ou dicionário-como semântica. Na maioria das linguagens, o que significa que você gostaria sht.Range["A1"] acesso. Isso é açúcar sintático, e realmente ele é acessado como qualquer outro método, a saber:

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

I tentou usar Boo, Ruby e IronRuby para repetir o código, usando tanto o estilo açúcar sintático e a chamada de método explícito. Em IronRuby, posso fazê-lo funcionar perfeitamente, mas apenas no interpretador de 32 bits . Em Ruby regular, que é um aplicativo de 32 bits em minha configuração, também funcionou bem. No interpretador de 64 bits, a propriedade Range não foi resolvido corretamente.

Assim que me levou a suspeitar que a Shell interativo Boo foi executado no modo de 64 bits e que interoperabilidade estava falhando por causa disso. Infelizmente, as mesmas questões reproduzidas depois de definir os binários vaia locais para executar no modo de 32 bits usando CORFLAGS.exe, então eu não acho que é a verdadeira questão.

O que fez o trabalho, porém, foi para importar explicitamente o Dotnet Interop Biblioteca Excel, bem como os espaços de nomes de serviços de interoperabilidade, assim:

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

Depois:

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

Todos estes trabalhos, mas eles exigem essencialmente você a desistir da "Scriptiness" você está acostumado a partir de fim de ligação (que é o que sua tipagem pato está fazendo).

Uma diferença de VB / VBScript que é verdade para a maioria das línguas (exceto C # 4.0) é que, geralmente, os parâmetros opcionais não são tratadas de forma transparente, de modo que você precisa olhar para a API com mais cuidado quando você lida com métodos que suporte os parâmetros opcionais (substituindo-os por System.Type.Missing ou o equivalente System.Reflection). Você acharia isso através de docs o Excel interoperabilidade, embora você provavelmente pode usar a reflexão para identificar os parâmetros marcados como opcional, se você achar que mais fácil do que olhando-o.

Porque Ruby tem uma solução razoável para a ligação tardia esses objetos, eu suspeito que há uma característica em falta (ou erro) em interoperabilidade cenários em Boo.

Editado para adicionar: Sam Ng escreve sobre suporte propriedade indexada em C # 4.0 ; os problemas descritos nos seu posto provavelmente se aplicam a Boo, também.