تجنب مكالمات العملية المتقاطعة عند القيام بأتمتة الكلمات عبر vb.net

Question

النسخة القصيرةلقد حصلت على كلمة addin في vb.net و vsto التي تكشف كائن com متوافق عبر word.comaddins.object ، بحيث يمكن تسمية وظيفة الإضافة الخارجية إلى الكلمة ، دون وصول إلى كلمة نفسها.

عملت هذه التقنية في VB6 ، ولكن مع VB.NET ، لا تزال تعمل ، لكنها أبطأ بكثير من نفس الرمز الذي يتم تشغيله مباشرة من الإضافة عبر جزء المهام ، كما لو كانت جميع المكالمات تتشابك عندما لا ينبغي أن تكون. x

النسخة الطويلةهذه الإضافات بشكل أساسي لا تقوم بأطنان من المعالجة على مستندات الكلمات. يمكن تشغيل الإضافة بطريقتين.

1. من داخل الكلمة ، باستخدام مجموعة المهام
2. خارجيا ، من خلال مجموعة من الفئات المعرضة لـ COM (لأنني يجب أن أتيح الوصول إلى الوظائف لتطبيقات عميل VB6.

ولكن ، ها هو فرك. يعرف أي شخص قام بأتمتة الكلمات على الإطلاق أن الرمز الذي يتم تشغيله بشكل مثالي مع Word (في هذه الحالة ، فإن مثيل الإضافة التي يتم تحميلها في حد ذاتها) ، سيتم تشغيلها بشكل غير مقبول بشكل غير مقبول عن العملية (أو العملية المتقاطعة).

هذا التطبيق لا يختلف.

منذ العصور ، استفدت من خدعة مفيدة للتحايل على هذه القضية.

1. إنشاء كلمة إضافة كالمعتاد
2. فضح كائن عبر خاصية Word.comaddin.Object التي ستتيح رمزًا خارجيًا للوصول إلى إضافتك.
3. في مشروعك الخارجي ، بدلاً من معالجة Word مباشرةً ، استخدم Application.comaddins Collection ، والعثور على الإضافات الخاصة بك ، واسترداد خاصية comaddin.object المكشوفة منها ، ثم استدعاء طريقة على هذا الكائن الذي يقوم بالعمل.

بالطبع ، ستظل مكالمة كائن comaddin.object الخاص بك هي عملية متقاطعة ، ولكن بمجرد أن يكون التنفيذ في الإضافة قيد التشغيل مع Word ، يمكن الآن أن تؤدي جميع معالجات كائن Word التي تريدها وهي سريعة لأنها " إعادة جميع المكالمات في العملية في تلك المرحلة.

التي عملت في أيام VB6 كوم.

لكنني قمت بتجميع ADDIN VB.NET VSTO ، وفضح كائن الإضافات الخاص بي عبر وظيفة requestComadDinaUtomationservice لكائن Connect's VSTO

يمكنني إجراء مكالمات في إضافتي من الخارج وهم جميعا يعملون تمامًا كما أتوقع منهم ، باستثناء كل شيء بطيء +، يشبه إلى حد كبير أن المكالمات في Word لا تزال قيد التنفيذ على الرغم من أن الكود يقوم بإجراء تلك المكالمات إلى Word هو جزء من Addin DLL الذي تم تحميله في العملية بواسطة Word!

وبطيئة كما في عامل حوالي 10 إلى 1 ؛ ما يستغرق تشغيل 3 ثوانٍ عند تشغيله مباشرة من الإضافة عبر جزء المهمة ، يستغرق حوالي 30 ثانية لتشغيله عند استدعاؤه من الكود الخارجي من خلال كائن comaddin.object.

أظن أنني أواجه نوعًا من المشكلات مع .NET AppDomains أو شيء ما ، وماذا عن + حقًا + يشكل مكالمات Cross Proc في .NET ، لكنني لم أجد شيئًا حتى الآن من شأنه أن يلمح إلى هذا النوع من الأشياء.

إن خطوتي التالية ، باستثناء بعض الرؤية الصوفية ، ستكون ترميز إعادة الشاشة ، والتي قد تصبح صعبة بسبب عدد القص في العناصر في اللعب.

أي أفكار؟

Answer 1

لسوء الحظ ، فإن تقنية ربط الحدث يذكر Thorben لن تعمل من أجل وضعي الخاص.

لذلك أنا أغلق هذا السؤال مع الحل البديل الذي ذكرته في التعليقات وسأكرر هنا ...

حسنًا ، ليس حلًا مثاليًا ، لكنني وجدت محلول + A +. لقد تضمن جهاز توقيت ، لذلك فهو بالتأكيد دون المستوى الأمثل ، عندما يتم تحميل الإضافة بواسطة Word ، (أي أثناء حدث بدء التشغيل) ، وتهيئة مؤقتًا (جهاز توقيت Winforms ، وليس مؤقتًا لخيوط) ، وتعيين فاصله على 500. عندما يكون خارجيًا. يتصل الكود بالإضافة عبر خاصية comaddin.object ، ويقوم بإجراء مكالمة في الإضافة ، وضبط علامة متغيرة ، يتم استطلاعها بواسطة المؤقت. عندما يرى الموقت تعيينه ، فإنه يعيد تعيين العلم ويؤدي الإجراء.

إنه ليس الحل النظيف الذي كنت أفضله ، لكن من السهل تنفيذها إلى حد ما ، وسهلة الفهم بشكل معتدل بعد الحقيقة ، وهو بالتأكيد يتجنب تباطؤ مكالمات COM XPROCESS إلى Word.

Answer 2

لقد قدمت نفس الملاحظات مع إضافة كلمة VSto الخاصة بي. ما أود إضافته هنا: عند إضافة الإجراء الخاص بك كمعالج نقرة إلى زر:

`this.testbutton.click += new Office._CommandBarButTonevents_ClickeventHandler (yoursprocedure) ؛ ´

وتنفيذ الإجراء المكلف في "YourProcedure" ، يمكنك الاتصال في مؤشر ترابط واجهة المستخدم في Word باستخدام

this.testbutton.execute () ؛

هذا ليس حلاً أنيقًا أيضًا ، ولكن ربما يكون مفيدًا إذا كان لديك أزرار جاهزة في شريط الأوامر.