أفضل الممارسات لتمرير المعلمات في Microsoft Visual Studio Tools for Office (VSTO) 3 (C#)

Question

تتطلب العديد من معلمات التفاعل مع نموذج كائن Office في VSTO معلمات كائن يتم تمريرها حسب المرجع، حتى عندما يكون النوع الافتراضي للمعلمة عبارة عن int أو سلسلة.

1. أفترض أنه تم استخدام هذه الآلية حتى يتمكن الكود من تعديل المعلمة، على الرغم من أنني لا أستطيع معرفة سبب ضرورة تمريرها ككائن عام بدلاً من الأنواع الأكثر ملاءمة لها.هل يمكن لأحد أن ينيرني؟

2. الآلية التي كنت أستخدمها (المستمدة من المساعدة وموارد MSDN) تقوم بشكل أساسي بإنشاء كائن عام يحتوي على البيانات المناسبة ثم يمررها إلى الطريقة، على سبيل المثال:

   الكائن nextBookmarkName = "NextContent";الكائن nextBookmark = this.Bookmarks.get_Item( ref nextBookmarkName ).Range;

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

يبدو أن هذا يحتوي على الكثير من التعليمات البرمجية الإضافية، لكن لا يمكنني رؤية طريقة أفضل للقيام بذلك.أنا متأكد من أنني أفتقد شيئًا ما؛ما هذا؟أم أن هذا هو حقا أفضل الممارسات؟

Answer 1

أعتقد أنه كان مجرد تصميم سيئ لنموذج كائن Word الأصلي.أعلم أن تمرير السلاسل حسب المرجع يمكن أن يكون أسرع قليلاً في عالم COM لأنه يتجنب الحاجة إلى عمل نسخة، لذلك ربما كان ذلك جزءًا من المبرر.لكن الجانب السلبي هو أن المستدعى يمكنه تعديل القيمة، وفي معظم الحالات مع Word تكون هذه معلمات إدخال.

أعتقد أن أسلوبك هو أفضل الممارسات.بالنسبة لملايين المعلمات الاختيارية التي تتطلبها العديد من أساليب نموذج كائن Word، يمكنك إنشاء حقل ثابت واحد "مفقود" مثل:

كائن مفقود = Type.Missing؛

// مثال اسم ملف الكائن = ...document.saveas (اسم الملف المرجع ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع المفقود ، المرجع ، المرجع مفتقد)؛

Answer 2

وأنا أتفق مع جو.حتى أنني قمت بتطوير بنيات وفئات مساعدة مثل هذه:

internal struct Argument
{
    internal static object False = false;

    internal static object Missing = System.Type.Missing;

    internal static object True = true;
}

و هذه:

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

وبعضها الآخر...

Answer 3

سأكون مهتمًا بهذا أيضًا.أقوم ببرمجة العديد من التطبيقات التي تستخدم الأتمتة في Word ولدي أشياء مثل

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

إنه أمر سيء للغاية، لكنها الطريقة الوحيدة التي أعرفها حتى الآن.

الشيء الوحيد الذي يمكنني التفكير فيه هو كتابة فئة مجمعة للوظائف المستخدمة بشكل متكرر ...

Answer 4

أعتقد أنه تم الاهتمام بكل هذا باستخدام VS.NET 2010 وبنيات اللغة الجديدة المقدمة في الإصدار c# 4.0 (ستحتوي لغة c# على وسيطات اختيارية).

شاهد الفيديو الخاص بـ Anders Hejlberg في PDC 2008 على القناة 9 للاطلاع على التغييرات المتعلقة بتطوير المكاتب.

لا أستطيع العثور على هذا الرابط ولكن هذا قد يكون مفيدًا أيضًا.
http://channel9.msdn.com/shows/Going+Deep/Inside-C-40-dynamic-type-اختياري-parameters-more-COM-Friendly/