Prática recomendada para passar parâmetros no Microsoft Visual Studio Tools for Office (VSTO) 3 (C#)

Question

Muitos dos parâmetros para interagir com o modelo Office Object no VSTO exigem parâmetros de objeto que são passados ​​por referência, mesmo quando o tipo nocional do parâmetro é um int ou string.

1. Suponho que esse mecanismo seja usado para que o código possa modificar o parâmetro, embora eu não consiga entender por que eles precisam ser passados ​​como objetos genéricos em vez de como seus tipos mais apropriados.Alguém pode me esclarecer?

2. O mecanismo que estou usando (criado na ajuda e nos recursos do MSDN) cria essencialmente um objeto genérico que contém os dados apropriados e depois os passa para o método, por exemplo:

   objeto nextBookmarkName = "NextContent";objeto nextBookmark = this.Bookmarks.get_Item (ref nextBookmarkName).Range;

   Microsoft.Office.Interop.Word.Range newRng = this.Range( ref nextBookmark, ref nextBookmark );

Parece muito código extra, mas não consigo ver uma maneira melhor de fazer isso.Tenho certeza de que estou perdendo alguma coisa;o que é?Ou esta é realmente a melhor prática?

Answer 1

Acho que foi apenas um design ruim do modelo de objeto original do Word.Eu sei que passar strings por referência pode ser um pouco mais rápido no mundo COM porque evita a necessidade de fazer uma cópia, então talvez isso fosse parte da justificativa.Mas a desvantagem é que o receptor pode modificar o valor e, na maioria dos casos, com o Word, eles são parâmetros de entrada.

Acho que sua técnica é a melhor prática.Para os milhões de parâmetros opcionais exigidos por muitos métodos de modelo de objeto do Word, você pode criar um único campo estático "ausente", algo como:

objeto ausente = Type.Missing;

Exemplo objeto fileName = ...documento. SaveAs(ref fileName, ref ausente, ref ausente, ref ausente, ref em falta, ref em falta, ref em falta, ref em falta, ref em falta, ref em falta, ref em falta, ref em falta, ref faltando, ref faltando);

Answer 2

Eu concordo com Joe.Até desenvolvi estruturas e classes auxiliares como esta:

internal struct Argument
{
    internal static object False = false;

    internal static object Missing = System.Type.Missing;

    internal static object True = true;
}

E este:

/// <summary>
/// Defines the "special characters"
/// in Microsoft Word that VSTO 1.x
/// translates into C# strings.
/// </summary>
internal struct Characters
{
    /// <summary>
    /// Word Table end-of-cell marker.
    /// </summary>
    /// <remarks>
    /// Word Table end-of-row markers are also
    /// equal to this value.
    /// </remarks>
    internal static string CellBreak = "\r\a";

    /// <summary>
    /// Word line break (^l).
    /// </summary>
    internal static string LineBreak = "\v";

    /// <summary>
    /// Word Paragraph break (^p).
    /// </summary>
    internal static string ParagraphBreak = "\r";
}

E mais alguns...

Answer 3

Eu também estaria interessado nisso.Estou codificando vários aplicativos que usam automação no Word e até tenho coisas como

object oFalse = false, oTrue = true, oOne = 1;

É muito desagradável, mas é a única maneira que conheço até agora.

A única coisa que consigo pensar é em escrever uma classe wrapper para as funções usadas com frequência...

Answer 4

Eu acho que tudo isso foi resolvido com o VS.NET 2010 e as novas construções de linguagem introduzidas no c# 4.0 (c# terá argumentos opcionais).

Veja o vídeo de Anders Hejlberg no PDC 2008 no canal 9 para conhecer as mudanças relacionadas ao desenvolvimento de escritórios.

Não consigo encontrar esse link, mas isso também pode ser útil.
http://channel9.msdn.com/shows/Going+Deep/Inside-C-40-dynamic-type-optional-parameters-more-COM-friendly/