Mejores prácticas para pasar parámetros en Microsoft Visual Studio Tools para Office (VSTO) 3 (C#)

Question

Muchos de los parámetros para interactuar con el modelo de objetos de Office en VSTO requieren parámetros de objeto que se pasan por referencia, incluso cuando el tipo teórico del parámetro es un int o una cadena.

1. Supongo que este mecanismo se utiliza para que el código pueda modificar el parámetro, aunque no puedo entender por qué es necesario pasarlos como objetos genéricos en lugar de sus tipos más apropiados.¿Alguien puede iluminarme?

2. El mecanismo que he estado usando (obtenido de la ayuda y de los recursos de MSDN) esencialmente crea un objeto genérico que contiene los datos apropiados y luego los pasa al método, por ejemplo:

   objeto nextBookmarkName = "SiguienteContenido";objeto nextBookmark = this.Bookmarks.get_Item (ref nextBookmarkName). Rango;

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

Esto parece mucho código adicional, pero no veo una mejor manera de hacerlo.Estoy seguro de que me falta algo;¿qué es?¿O es esta realmente la mejor práctica?

Answer 1

Creo que fue simplemente un mal diseño del modelo de objetos original de Word.Sé que pasar cadenas por referencia puede ser un poco más rápido en el mundo COM porque evita la necesidad de hacer una copia, así que quizás eso fue parte de la justificación.Pero la desventaja es que el destinatario puede modificar el valor y, en la mayoría de los casos, con Word son parámetros de entrada.

Creo que tu técnica es la mejor práctica.Para los millones de parámetros opcionales que requieren muchos de los métodos del modelo de objetos de Word, puede crear un único campo estático al que "falte" algo como:

objeto faltante = Tipo.Missing;

// Ejemplo de objeto FileName = ...documento. Savas (Ref Ref File Name, Ref Falting, Ref Falting, Ref Falling, Ref Falling, Ref Falling, Ref Falling, Ref Falling, Ref Faltar, Ref Faltar, Ref. Falta, Ref Falta, Ref Falta, Ref. desaparecido);

Answer 2

Estoy de acuerdo con Joe.Incluso desarrollé estructuras y clases auxiliares como esta:

internal struct Argument
{
    internal static object False = false;

    internal static object Missing = System.Type.Missing;

    internal static object True = true;
}

Y éste:

/// <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";
}

Y algunos más...

Answer 3

A mí también me interesaría esto.Estoy codificando varias aplicaciones que usan automatización en Word e incluso tengo cosas como

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

Es muy desagradable, pero es la única forma que conozco hasta ahora.

Lo único que se me ocurre es escribir una clase contenedora para las funciones utilizadas con frecuencia...

Answer 4

Creo que todo esto se soluciona con VS.NET 2010 y las nuevas construcciones de lenguaje introducidas en c# 4.0 (c# tendrá argumentos opcionales).

Vea el vídeo de Anders Hejlberg en PDC 2008 en el canal 9 para conocer los cambios relacionados con el desarrollo de oficinas.

No encuentro ese enlace pero esto también podría ser útil.
http://channel9.msdn.com/shows/Going+Deep/Inside-C-40-dynamic-type-optional-parameters-more-COM-friendly/