Méthode recommandée pour la transmission de paramètres dans VSTO (Visual Studio Tools for Office) 3 (C #)

Question

De nombreux paramètres d'interaction avec le modèle d'objet Office dans VSTO nécessitent des paramètres d'objet transmis par référence, même lorsque le type notionnel du paramètre est un entier ou une chaîne.

1. Je suppose que ce mécanisme est utilisé pour que le code puisse modifier le paramètre, bien que je ne puisse pas comprendre pourquoi ils doivent être transmis sous forme d'objet générique plutôt que sous leur type plus approprié. Quelqu'un peut-il m'éclairer?

2. Le mécanisme que j'ai utilisé (cribbed depuis l'aide et les ressources MSDN) crée essentiellement un objet générique contenant les données appropriées, puis transmis à la méthode, par exemple:

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

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

Cela ressemble à beaucoup de code supplémentaire, mais je ne vois pas de meilleure façon de le faire. Je suis sûr que je manque quelque chose; qu'Est-ce que c'est? Ou est-ce vraiment la meilleure pratique?

Answer 1

Je pense que c'était simplement une mauvaise conception du modèle d'objet Word original. Je sais que le passage de chaînes par référence peut être légèrement plus rapide dans le monde COM, car il évite la nécessité de faire une copie, alors peut-être que cela faisait partie de la justification. Mais l'inconvénient est que l'appelé peut modifier la valeur et, dans la plupart des cas, avec Word, ce sont des paramètres d'entrée.

Je pense que votre technique est la meilleure pratique. Pour les millions de paramètres facultatifs requis par de nombreuses méthodes de modèle objet Word, vous pouvez créer un seul champ statique "manquant". quelque chose comme:

objet manquant = Type.Missing;

// Exemple objet nomFichier = ... document.SaveAs (ref nomfichier, ref manquant, ref manquant, ref manquant,                 ref manquant, ref manquant, ref manquant, ref manquant, ref manquant,                 ref manquant, ref manquant, ref manquant, ref manquant, ref manquant,                 ref manquant, ref manquant);

Answer 2

Je suis d'accord avec Joe. J'ai même développé des structures et des classes d'aide comme celle-ci:

internal struct Argument
{
    internal static object False = false;

    internal static object Missing = System.Type.Missing;

    internal static object True = true;
}

Et celui-ci:

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

Et quelques autres ...

Answer 3

Cela m'intéresserait aussi. Je code plusieurs applications qui utilisent l'automatisation dans Word et j'ai même des choses comme

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

C'est très méchant, mais c'est la seule façon que je connaisse jusqu'à présent.

La seule chose à laquelle je peux penser est d'écrire une classe wrapper pour les fonctions fréquemment utilisées ...

Answer 4

Je pense que tout cela est pris en charge avec VS.NET 2010 et les nouvelles constructions de langage introduites dans c # 4.0 (c # aura des arguments optionnels).

Voir la vidéo de Anders Hejlberg lors du PDC 2008 sur le canal 9 pour connaître les changements liés au développement des bureaux.

Je ne trouve pas ce lien, mais cela pourrait aussi être utile.
http : //channel9.msdn.com/shows/Going+Deep/Inside-C-40-dynamic-type-optional-parameters-more-COM-friendly/