نظرة عامة على الوظائف الإضافية لـ WPF
.NET Framework يتضمن طراز الوظائف الإضافية الذي يمكن للمطورين استخدامها لإنشاء التطبيقات التي تدعم الوظائف الإضافية القابلة للتوسع. يسمح هذا الطراز للوظيفة الإضافية بإنشاء الوظائف الإضافية التي تتكامل مع و توسع الأداء الوظيفي للتطبيق. في بعض السيناريوهات، التطبيقات تحتاج أيضاً إلى عرض واجهات المستخدم التي يتم توفيرها من قبل الوظائف الإضافية. يوضح هذا الموضوع كيفية يقوم WPF بتقوية طراز الوظائف الإضافية .NET Framework لتمكين هذه السيناريوهات, البنية خلفه, فوائده و القيود الخاصة به.
يشتمل هذا الموضوع على الأقسام التالية.
- المتطلبات الأساسية
- نظرة عامة على الوظائف الإضافية
- نظرة عامة حو طراز الوظيفة الإضافية NET framework.
- وظائف إضافية ل WPF
- الوظيفة الإضافية تقوم بإرجاع واجهة مستخدم
- الوظيفة الإضافية هي واجهة مستخدم
- إرجاع UIs متعددة من الوظيفة الإضافية
- الوظائف الإضافية و تطبيقات المستعرض XAML
- بنية الوظيفة الإضافية WPF
- فوائد الوظائف الإضافية WPF
- قيود الوظائف الإضافية WPF
- أمثلية الأداء
- موضوعات ذات صلة
المتطلبات الأساسية
معرفة طراز الوظيفة الإضافية .NET Framework مطلوب. لمزيد من المعلومات، راجع الوظائف الإضافية ووحدات الامتداد.
نظرة عامة على الوظائف الإضافية
لتجنب تعقيدات إعادة التحويل البرمجي للتطبيق و إعادة النشر لتضمين وظائف جديدة, تقوم التطبيقات بتنفيذ آليات قابلة للتوسع التي تسمح للمطورين (كل من الجهة و الجهة خارجية) لإنشاء تطبيقات أخرى التي تتكامل معها. الطريقة الأكثر شيوعا لدعم هذا النوع من القابلية للتوسع هو خلال استخدام الوظائف الإضافية (تعرف أيضاً باسم "الإضافية" و "المكون الإضافي"). أمثلة لتطبيقات حقيقية التي تكشف القابلية للتوسع مع الوظائف الإضافية تتضمن:
الوظائف الإضافية في Internet Explorer.
مكون إضافي Windows Media Player.
الوظائف الإضافية Visual Studio.
على سبيل المثال، طراز الوظيفة الإضافية Windows Media Player تسمح لمطوري الجهة الخارجية تنفيذ "الوظائف الإضافية" التي توسع Windows Media Player بعدة طرق، بما في ذلك إنشاء وحدات فك ترميز و الترميز لتنسيقات الوسائط الغير المدعمة أصلاً بواسطة Windows Media Player (على سبيل المثال، DVD ، MP3) تأثيرات الصوت و الأسطح. كل طراز وظيفة إضافية يتم بنائه لكشف الوظيفة الفريدة إلى تطبيق, على الرغم من وجود العديد من الوحدات و السلوكيات المشتركة في كافة طرازات الوظيفة الإضافية.
الثلاث وحدات الرئيسية من حلول القابلة للتوسيع للوظائف الإضافية النموذجية هي عقود، الوظائف الإضافية و التطبيقات المضيفة. العقود تعرف كيفية تكامل الوظائف الإضافية مع التطبيقات المضيفة بطريقتين:
تكامل الوظائف الإضافية مع الوظيفة التي يتم تطبيقها من قبل التطبيقات المضيفة.
كشف التطبيقات المضيفة وظيفة الوظائف الإضافية للتكامل معها.
كي يمكن استخدام الوظائف الإضافية, تحتاج التطبيقات المضيفة إلى العثور عليها و تحميل عليها في وقت التشغيل. بالتالي، التطبيقات التي تدعم الوظائف الإضافية لديها المسؤوليات الإضافية التالية:
الاكتشاف: البحث عن الوظائف الإضافية التي تلتزم بالعقود المدعمة من قبل التطبيقات المضيفة.
التنشيط: تحميل, تشغيل و تأسيس اتصال مع الوظائف الإضافية.
العزل: استخدام مجالات التطبيق أو العمليات لإنشاء حدود عزل التي تحمي التطبيقات من مشاكل الأمان و التنفيذ المحتملة مع الوظائف الإضافية.
الاتصال: السماح للوظائف الإضافية و للتطبيقات المضيفة بالاتصال مع بعضها البعض عبر حدود العزل بواسطة استدعاء الأساليب و تمرير البيانات.
إدارة مدة البقاء: تحميل و إلغاء تحميل مجالات التطبيق و العمليات بطريقة نظيفة متوقعة (راجع مجالات التطبيق).
تعيين إصدار: التأكد من أن التطبيقات المضيفة و الوظائف الإضافية لا يزال يمكنها الاتصال عند إنشاء إصدارات جديدة من أي منهم.
في النهاية، تطوير طراز الوظيفة الإضافية قوي هو undertaking غير عادي. لهذا السبب، .NET Framework يوفر بنية أساسية لإنشاء طرازات الوظيفة الإضافية.
.gif "ملاحظة") ملاحظة |
|---|
للحصول على المزيد من المعلومات المفصلة على الوظائف الإضافية, راجع الوظائف الإضافية ووحدات الامتداد. |
نظرة عامة حو طراز الوظيفة الإضافية NET framework.
طراز الوظيفة الإضافية .NET Framework, الموجود في مساحة اسم System.AddIn, يحتوي على مجموعة من الأنواع التي تم تصميمها لتبسيط تطوير قابلية التوسعة للوظيفة الإضافية. الوحدة الأساسية لطراز الوظيفة الإضافية .NET Framework هو العقد، و الذي يقوم بتعريف كيفية اتصال التطبيق المضيف و الوظيفة الإضافية مع بعضها البعض. العقد مكشوف للتطبيق المضيف باستخدام طريقة عرض الخاصة بالتطبيق المضيف من العقد. Likewهوe، في الوظيفة الخاصة عرض للعقد هو إلى الوظيفة الإضافية. محول هو المستخدم للسماح مضيف التطبيق ووظيفة الإضافية للاتصال بين طرق العرض الخاصة بهم من اتفاق. تتم الإشارة إلى العقود, طرق العرض, و محولات كمقاطع و مجموعة المقاطع ذات الصلة تؤسس تدفقات . التدفقات هي الأساس الذي به طراز الوظيفة الإضافية .NET Framework يدعم الاكتشاف, التنشيط, عزل الأمان، عزل التنفيذ (باستخدام مجالات التطبيق و العمليات)، الاتصال, إدارة مدة البقاء, و تعيين الإصدارات.
مجموع هذا الدعم يسمح للمطورين بإنشاء الوظائف الإضافية التي تتكامل مع وظيفة التطبيق المضيف. مع ذلك، تتطلب بعض السيناريوهات من التطبيقات المضيفة أن تعرض واجهات المستخدم الموفرة من قبل الوظائف الإضافية. لأن كل تقنية عرض التقديمي في .NET Framework تحتوي على الطراز الخاص به لتنفيذ واجهات المستخدم، طراز الوظيفة الإضافية .NET Framework لا يدعم أي تقنية عرض التقديمي معينة. بدلاً من ذلك، يقوم WPF بتوسيع طراز الوظيفة الإضافية .NET Framework مع دعم واجهة المستخدم للوظائف الإضافية.
وظائف إضافية ل WPF
WPF، بالاشتراك مع طراز الوظيفة الإضافية .NET Framework, يسمح لك بمخاطبة تشكيلة واسعة من السيناريوهات التي تتطلب من التطبيقات المضيفة أن تعرض واجهات المستخدم من الوظائف الإضافية. بشكل خاص، تتم معالجة هذه السيناريوهات WPF مع طرازي البرمجة التاليين:
الوظائف الإضافية تقوم بإرجاع UI. الوظيفة الإضافية تقوم بإرجاع واجهة المستخدم إلى التطبيق المضيف بواسطة استدعاء أسلوب, كما هو محدد بواسطة العقد. هذا السيناريو يُستخدم في الحالات التالية:
مظهر واجهة المستخدم الذي تم إرجاعه بواسطة الوظيفة الإضافية يعتمد على البيانات أو الشروط الموجودة فقط عند وقت التشغيل مثل التقارير التي يتم إنشاؤها بشكل حيوي.
واجهة المستخدم للخدمات الموفرة من قبل الوظيفة الإضافية تختلف عن واجهة المستخدم من التطبيقات المضيفة التي يمكنها استخدام الوظيفة الإضافية.
الوظيفة الإضافية بشكل أساسي تنفذ خدمة من أجل التطبيق المضيف و تبلغ الحالة إلى التطبيق المضيف مع واجهة المستخدم.
الوظائف الإضافية هي UI. الوظيفة الإضافية هي واجهة المستخدم ، كما هو محدد بواسطة العقد. هذا السيناريو يُستخدم في الحالات التالية:
لا توفر الوظيفة الإضافية خدمات غير أن تكون معروضة, مثل إعلان.
واجهة المستخدم للخدمات المتوفرة من قبل الوظيفة الإضافية هي مشتركة لكافة التطبيقات المضيفة التي يمكن استخدام هذه الوظيفة الإضافية، مثل الحاسبة أو منتقي الألوان.
تتطلب هذه السيناريوهات أن كائنات واجهة المستخدم يمكن تمريرها بين التطبيق المضيف و مجالات تطبيق الوظيفة الإضافية. بما أن طراز الوظيفة الإضافية .NET Framework تعتمد على العمل عن بُعد للاتصال بين مجالات التطبيق, يجب أن تكون الكائنات التي تم تمريرها بينهم remotable.
كائن remotable هو عبارة عن مثيل لفئة التي تفعل واحد أو أكثر مما يلي:
مشتق من فئة MarshalByRefObject.
ينفذ واجهة ISerializable .
لديه سمة SerializableAttribute مُطبقة.
| ملاحظة |
|---|
لمزيد من المعلومات حول إنشاء كائنات .NET Framework عن بعد, راجع Making Objects Remotable. |
أنواع WPF واجهة المستخدم لا تكون remotable. لحل المشكلة، يقوم WPF بتوسيع طراز الوظيفة الإضافية .NET Framework لتمكين WPF واجهة المستخدم التي تم إنشاؤها بواسطة الوظائف الإضافية من أن يتم عرضها من التطبيقات المضيفة. يتم توفير هذا الدعم بواسطة WPF بواسطة نوعين: واجهة INativeHandleContract و اثنين من الأساليب الثابتة المطبقة بواسطة فئة FrameworkElementAdapters: ContractToViewAdapter وViewToContractAdapter عند مستوى عالي يتم استخدام هذه الأنواع و الأساليب بالطريقة التالية:
WPF يتطلب أن واجهات المستخدم المتوفرة من قبل الوظائف الإضافية تكون عبارة عن فئات مشتقة مباشرة أو غير مباشرة من FrameworkElement مثل الأشكال، عناصر التحكم, عناصر التحكم المستخدم، لوحات التخطيط و الصفحات.
أينما يقوم العقد بتعريف أنه سيتم تمرير واجهة مستخدم بين الوظيفة الإضافية و التطبيق المضيف، يجب تعريفها مثل INativeHandleContract (ليس FrameworkElement); INativeHandleContract هو تمثيل remotable من الوظيفة الإضافية واجهة المستخدم التي يمكن تمريرها عبر حدود العزل.
قبل تمريره من مجال تطبيق الوظيفة الإضافية، يتم حزم FrameworkElement مثل INativeHandleContract بواسطة استدعاء ViewToContractAdapter.
بعد تمريره إلى مجال التطبيق للتطبيق المضيف،يجب إعادة حزم INativeHandleContract مثل FrameworkElement بواسطة استدعاء ContractToViewAdapter.
كيفية استخدام INativeHandleContract، ContractToViewAdapter، و ViewToContractAdapter يعتمد على السيناريو المعين. توفر المقاطع التالية التفاصيل لكل طراز برمجة.
الوظيفة الإضافية تقوم بإرجاع واجهة مستخدم
حتى تقوم الوظيفة الإضافية بإرجاع واجهة المستخدم إلى تطبيق مضيف, مطلوب التالي:
يجب إنشاء التطبيق المضيف، الوظيفة الإضافية، و التدفقات كما هو موضح بواسطة وثائق .NET Framework الوظائف الإضافية ووحدات الامتداد.
يجب أن يقوم العقد بتنفيذ IContract و، لإرجاع واجهة المستخدم ، يجب أن يقوم العقد بتعريف أسلوب بقيمة إرجاع من نوع INativeHandleContract.
واجهة المستخدم التي يتم تمريرها بين الوظيفة الإضافية و التطبيق المضيف يجب أن تشتق مباشرة أو غير مباشرة من FrameworkElement.
واجهة المستخدم الذي يتم إرجاعه بواسطة الوظيفة الإضافية يجب تحويلها من FrameworkElement إلى INativeHandleContract قبل تخطي حدود العزل.
واجهة المستخدم التي تم إرجاعها يجب أن يتم تحويلها من INativeHandleContract إلى FrameworkElement بعد تخطي حدود العزل.
يعرض التطبيق المضيف FrameworkElement التي تم إرجاعها.
للحصول على مثال يوضح كيفية تنفيذ الوظيفة الإضافية التي تقوم بإرجاع واجهة المستخدم, راجع كيفية القيام بما يلي: إنشاء الوظائف الإضافية التي تقوم بإرجاع UI.
الوظيفة الإضافية هي واجهة مستخدم
عندما تكون الوظيفة الإضافية هي واجهة المستخدم، مطلوب التالي:
يجب إنشاء التطبيق المضيف، الوظيفة الإضافية، و التدفقات كما هو موضح بواسطة وثائق .NET Framework الوظائف الإضافية ووحدات الامتداد.
واجهة العقد للوظيفة الإضافية يجب أن تنفذ INativeHandleContract.
الوظيفة الإضافية التي يتم تمريرها إلى التطبيق المضيف يجب أن تشتق مباشرة أو غير مباشرة من FrameworkElement.
الوظيفة الإضافية يجب تحويلها من FrameworkElement إلى INativeHandleContract قبل تخطي حدود العزل.
الوظيفة الإضافية يجب تحويلها من INativeHandleContract إلى FrameworkElement بعد تخطي حدود العزل.
يعرض التطبيق المضيف FrameworkElement التي تم إرجاعها.
للحصول على مثال يوضح كيفية تنفيذ الوظيفة الإضافية التي تقوم بإرجاع واجهة المستخدم, راجع كيفية القيام بما يلي: إنشاء الوظائف الإضافية التي تقوم بإرجاع UI.
إرجاع UIs متعددة من الوظيفة الإضافية
الوظائف الإضافية غالباً ما توفر عدة واجهات المستخدم للتطبيقات المضيفة للعرض. على سبيل المثال، خذ بعين الاعتبار الوظيفة الإضافية التي هي واجهة المستخدم التي توفر أيضاً معلومات الحالة إلى التطبيق المضيف, أيضاً كـواجهة المستخدم. وظيفة إضافية مثل ذلك يمكن تنفيذها باستخدام مجموعة من التقنيات من كلا من طراز وظيفة إضافية تقوم بإرجاع واجهة المستخدم و وظيفة إضافية هي واجهة المستخدم.
الوظائف الإضافية و تطبيقات المستعرض XAML
في الأمثلة حتى الآن تم تثبيت التطبيق المضيف كتطبيق مستقل. لكن تطبيقات مستعرض XBAP (XBAP) يمكنه أيضاً استضافة الوظائف الإضافية, albeit مع متطلبات البناء و التنفيذ الإضافية التالية:
بيان تطبيق XBAP يجب تكوينه بشكل خاص لتحميل التدفقات (المجلدات و التجميعات) و تجميع الوظيفة الإضافية إلى ذاكرة التخزين المؤقت لتطبيق ClickOnce على جهاز العميل, في نفس المجلد ك XBAP.
التعليمات البرمجية XBAP لاكتشاف و تحميل الوظائف الإضافية يجب أن يستخدم ذاكرة التخزين المؤقت لتطبيق ClickOnce لXBAP كتدفقات و موقع الوظيفة الإضافية.
يجب أن يقوم XBAP بتحميل الوظيفة الإضافية في سياق أمان خاص إذا كانت الوظيفة الإضافية تشير إلى الملفات غير المحكمة التي توجد عند موقع الأصل; عند استضافتها بواسطة تطبيقات XBAP ،الوظائف الإضافية يمكنها فقط الإشارة إلى الملفات غير المحكمة التي توجد في موقع الأصل للتطبيق المضيف.
يتم وصف هذه المهام بالتفصيل في الأقسام الفرعية التالية.
تكوين التدفقات و الوظيفة الإضافية لنشر ClickOnce
تطبيقات XBAP يتم تنزيلها إلى و تشغيلها من مجلد آمن في ذاكرة التخزين المؤقتة للنشر ClickOnce. من أجل أن يستضيف XBAP وظيفة إضافية، التدفقات و تجميع الوظيفة الإضافية يجب أيضاً تحميله إلى مجلد الآمن. لتحقيق هذا, تحتاج إلى تكوين بيان التطبيق لتضمين كلا من التدفقات و تجميع الوظيفة الإضافية للتنزيل. يتم هذا بسهولة في Visual Studio، على الرغم من أن التدفقات و تجميع الوظيفة الإضافية يجب أن يكون في مجلد الجذر الخاص بمشروع XBAP المضيف من أجل أن يكشف Visual Studio عن تجميعات التدفقات.
بالتالي، الخطوة الأولى لإنشاء التدفقات و تجميع الوظيفة الإضافية إلى الجذر الخاص بمشروع XBAP عن طريق إعداد ناتج الإنشاء لكل من مشاريع تجميع التدفقات و تجميع الوظيفة الإضافية. يعرض الجدول التالي مسارات ناتج الإنشاء لمشاريع تجميع التدفقات و مشروع تجميع الوظيفة الإضافية الموجودة في نفس الحل و مجلد الجذر كمشروع XBAP المضيف.
الجدول 1: مسارات ناتج الإنشاء لتجميعات التدفقات المستضافة بواسطة XBAP
مشروع تجميع التدفقات |
بناء مسار الإخراج |
|---|---|
عقد |
.. \HostXBAP\Contracts\ |
عرض الوظيفة الإضافية |
.. \HostXBAP\AddInViews\ |
محول جانب الوظيفة الإضافية |
.. \HostXBAP\AddInSideAdapters\ |
محول جانب المضيف |
.. \HostXBAP\HostSideAdapters\ |
الوظيفة الإضافية |
.. \HostXBAP\AddIns\WPFAddIn1 |
الخطوة التالية هي تحديد تجميعات التدفقات و تجميع الوظيفة الإضافية مثل ملفات محتوى تطبيقات XBAP في Visual Studio عن طريق القيام بما يلي:
تضمين تجميع التدفقات و الوظيفة الإضافية في المشروع عن طريق النقر بالزر الأيمن فوق كل مجلد تدفقات في "مستكشف الحلول" و اختيار تضمين في المشروع.
إعداد إجراء الإنشاء لكل تجميع تدفقات و تجميع الوظيفة الإضافية إلى المحتوى من خلال إطار الخصائص".
الخطوة الأخيرة هي تكوين بيان التطبيق لتضمين ملفات تجميع التدفقات و ملف تجميع الوظيفة الإضافية للتنزيل. يجب أن تكون هذه الملفات موجودة في المجلدات في جذر المجلد في ذاكرة التخزين المؤقت ClickOnce الذي يشغلها تطبيق XBAP. يمكن الحصول على التكوين في Visual Studio عن طريق القيام بما يلي:
انقر بزر الماوس الأيمن فوق مشروع XBAP, انقر فوق الخصائص, انقر فوق نشر, و ثم انقر فوق زر ملفات التطبيق.
في مربع حوار ملفات التطبيق, قم بتعيين حالة النشر لكل من التدفقات و الوظيفة الإضافية DLL إلى تضمين (تلقائي), و تعيين مجموعة التنزيل لكل من التدفقات و الوظيفة الإضافية DLL إلى (مطلوب).
استخدام التدفقات و الوظيفة الإضافية من قاعدة التطبيق
عندما يتم تكوين التدفقات و الوظيفة الإضافية لنشر ClickOnce, يتم تنزيلها إلى نفس مجلد ذاكرة التخزين المؤقت ClickOnce مثل XBAP. لاستخدام التدفقات و الوظيفة الإضافية من XBAP، التعليمات البرمجية XBAP يجب أن تحصل عليهم من قاعدة التطبيق. الأعضاء و الأنواع المختلفة من طراز الوظيفة الإضافية .NET Framework لاستخدام التدفقات و الوظيفة الإضافية توفر دعم خاص لهذا السيناريو. أولاً، يتم تعريف المسار بواسطة قيمة تعداد ApplicationBase. تستخدم هذه القيمة مع التحميلات الزائدة لأعضاء الوظيفة الإضافية ذات الصلة لاستخدام التدفقات التي تتضمن ما يلي:
الوصول إلى موقع المضيف من الأصل
للتأكد من أن وظيفة الإضافية تشير إلى الملفات من موقع الأصل, الوظيفة الإضافية يجب تحميلها مع عزل الأمان المكافئ إلى التطبيق المضيف. يتم تعريف مستوى الأمان بواسطة قيمة التعداد AddInSecurityLevel.Host و تمريرها إلى أسلوب Activate عند تنشيط الوظيفة الإضافية.
بنية الوظيفة الإضافية WPF
في المستوى الأعلى, كما قد شاهدنا، WPF يتيح للوظائف الإضافية .NET Framework تنفيذ واجهات المستخدم (التي تشتق مباشرة أو غير مباشرة من FrameworkElement) باستخدام INativeHandleContract، ViewToContractAdapter و ContractToViewAdapter. تكون النتيجة أن التطبيق المضيف يتم إرجاعه FrameworkElement التي يتم عرضها من واجهة المستخدم في التطبيق المضيف.
لسيناريوهات الوظيفة الإضافية واجهة المستخدم البسيطة, هذا هو قدر التفاصيل التي يحتاجها المطور. للسيناريوهات الأكثر تعقيداً, خاصة تلك التي تحاول استخدام خدمات WPF إضافية مثل التخطيط و الموارد و ربط البيانات, معرفة أكثر تفصيلاً لكيف WPF يوسع طراز الوظيفة الإضافية .NET Framework مع دعم واجهة المستخدم مطلوبة لفهم فوائده و قيوده.
أساسياً، WPF لا يقوم بتمرير واجهة المستخدم من الوظيفة الإضافية إلى التطبيق المضيف; بدلاً من ذلك، WPF يقوم بتمرير مؤشر الإطار Win32 إلى واجهة المستخدم باستخدام إمكانية التشغيل التفاعلي WPF. كذلك, عند يتم تمرير واجهة المستخدم من الوظيفة الإضافية إلى التطبيق المضيف، يحدث ما يلي:
على جانب الوظيفة الإضافية, WPF تكتسب مؤشر إطار لواجهة المستخدم الذي سيتم عرضه بواسطة التطبيق المضيف. يتم تغليف مؤشر الإطار من قبل فئة WPF داخلية التي تشتق من HwndSource و تنفيذ INativeHandleContract. يتم إرجاع مثيل من هذه الفئة من قبل ViewToContractAdapter و يتم تنظيمها و إرسالها من مجال التطبيق الخاص بالوظيفة الإضافية إلى مجال التطبيق الخاص بالتطبيق المضيف.
على جانب التطبيق المضيف، WPF يعيد حزم HwndSource كفئة WPF داخلية التي تشتق من HwndHost و تستهلك INativeHandleContract. يتم إرجاع مثيل من هذه الفئة من قبل ContractToViewAdapter إلى التطبيق المضيف.
HwndHost موجود لعرض واجهات المستخدم، المعرّفة بواسطة مؤشرات الإطار من WPF واجهات المستخدم. لمزيد من المعلومات، راجع نظرة عامة حول التشغيل التفاعلي ل Win32 و WPF.
في ملخص، INativeHandleContract، ViewToContractAdapter، و ContractToViewAdapter موجود للسماح لمؤشر الإطار لWPF واجهة المستخدم أن يتم تمريره من الوظيفة الإضافية إلى التطبيق المضيف, حيث يتم تغليفها بواسطة HwndHost و عرضها واجهة المستخدم الخاص بالتطبيق المضيف.
| ملاحظة |
|---|
لأن التطبيق المضيف يحصل على HwndHost، التطبيق المضيف لا يمكنه تحويل الكائن الذي يتم إرجاعه بواسطة ContractToViewAdapter إلى النوع الذي هي مطبقة به عن طريق الوظيفة الإضافية (على سبيل المثال، UserControl). |
بطبيعته, HwndHost لديه بعض القيود التي تؤثر على كيفية استخدام التطبيقات المضيفة لهم. مع ذلك، يقوم WPF بتوسيع HwndHost مع عدة قدرات لسيناريوهات الوظيفة الإضافية. هذه الفوائد و القيود موضحة أدناه.
فوائد الوظائف الإضافية WPF
لأن WPFالوظيفة الإضافيةواجهات المستخدم يتم عرضهم من التطبيقات المضيفة باستخدام فئة داخلية التي تشتق من HwndHost، تلك واجهات المستخدم مقيدة بقدرات HwndHost فيما يتعلق بخدمات WPF واجهة المستخدم مثل التخطيط, التقديم، ربط البيانات، الأنماط، القوالب، و الموارد. مع ذلك، WPF يقوي الفئة الفرعية HwndHost الداخلية الخاصة به مع قدرات إضافية التي تتضمن ما يلي:
التبويب بين واجهة المستخدم الخاص بالتطبيق المضيف و واجهة المستخدم الخاص بالوظيفة الإضافية. لاحظ أن طراز البرمجة "الوظيفة الإضافية هي واجهة المستخدم" يتطلب محول الوظيفة الإضافية لتجاوز QueryContract لتمكين التبويب، ما إذا كانت الوظيفة الإضافية موثوق بها ثقة كاملة أو موثوق بها جزئيًا.
تكريم متطلبات الوصول للوظيفة الإضافية واجهات المستخدم التي يتم عرضها من التطبيق المضيف واجهات المستخدم.
تمكين تطبيقات WPF لتشتغل بأمان في عدة سيناريوهات مجال التطبيق.
منع الوصول غير القانوني إلى معالجة إطار الوظيفة الإضافية واجهة المستخدم عند تشغيل الوظائف الإضافية مع عزل أمان (أي، حماية أمان الثقة الجزئية). استدعاء ViewToContractAdapter يضمن هذا الأمان:
لطراز برمجة "الوظيفة الإضافية التي ترجع واجهة المستخدم"، الطريقة الوحيدة لتمرير مؤشر الإطار للوظيفة الإضافية واجهة المستخدم عبر حد العزل هو باستدعاء ViewToContractAdapter.
لطراز برمجة " الوظيفة الإضافية هي واجهة المستخدم", تجاوز QueryContract على محول الوظيفة الإضافية و استدعاء ViewToContractAdapter (كما هو موضح في الأمثلة السابقة) مطلوب, كاستدعاء تنفيذ QueryContract الخاص بمحول الوظيفة الإضافية من محول جانب المضيف.
توفير أمان تنفيذ مجال تطبيق متعددة. بسبب الحدود الموضوعة مع مجالات التطبيق, الاستثناءات غير المُعالجَة التي تلقى في مجالات تطبيق الوظيفة الإضافية تتسبب في تعطل التطبيق بالكامل, بالرغم من وجود حد العزل. مع ذلك، طراز الوظيفة الإضافية WPF و .NET Framework يوفر طريقة بسيطة للتغلب على هذه المشكلة وتحسين استقرار التطبيق. الوظيفة الإضافية WPF التي تعرض واجهة المستخدم تقوم بإنشاء Dispatcher لمؤشر الترابط الذي يتم تشغيل مجال التطبيق عليه، إذا كان التطبيق المضيف هو تطبيق WPF. يمكنك الكشف عن كافة الاستثناءات غير المُعالَجة التي تحدث في مجال التطبيق بواسطة معالجة حدث UnhandledException من Dispatcher الخاص بالوظيفة الاضافية WPF. يمكنك الحصول على Dispatcher من خاصية CurrentDispatcher.
قيود الوظائف الإضافية WPF
بعد الفوائد التي يضيفها WPF إلى السلوك الافتراضي الذي تم توفيره من قبل HwndSource، HwndHost، و مقابض الإطار, أيضاً توجد قيود للوظيفة الإضافية واجهات المستخدم التي يتم عرضها من التطبيقات المضيفة:
الوظيفة الإضافية واجهات المستخدم التي يتم عرضها من التطبيق المضيف لا تأخذ بعين الاعتبار سلوك لقطة التطبيق المضيف.
المفهوم airspace في سيناريوهات إمكانية التشغيل التفاعلي تنطبق أيضاً على الوظائف الإضافية (راجع التشغيل التفاعلي WPF: نظرة عامة p,g مناطق hgإطار و "airspace").
خدمات واجهة المستخدم للتطبيق المضيف, مثل وراثة المورد, ربط البيانات و commanding، لا تتوفر تلقائياً للوظيفة الإضافية واجهات المستخدم. لتوفير هذه الخدمات إلى الوظيفة الإضافية، تحتاج إلى تحديث التدفقات.
الوظيفة الإضافية واجهة المستخدم لا يمكن تدويرها, تغيير حجمها ، انحرافها, أو تتأثر بتحويل (راجع نظرة عامة على التحويلات).
المحتوى داخل الوظيفة الإضافية واجهات المستخدم التي يتم تقديمها بواسطة عمليات الرسم من مساحة اسم System.Drawing يمكن أن تتضمن خلط ألفا. مع ذلك، كلا من الوظيفة الإضافية واجهة المستخدم و التطبيق المضيف واجهة المستخدم الذي يحتوي عليه يجب أن يكونوا 100 % معتم; بمعنى آخر، خاصية Opacity على كليهما يجب تعيينها إلى 1.
إذا كانت خاصية AllowsTransparency من الإطار في التطبيق المضيف الذي يحتوي على الوظيفة الإضافية واجهة المستخدم معينة إلى true, الوظيفة الإضافية تكون غير مرئية. و ينطبق هذا حتى إذا كانت الوظيفة الإضافية واجهة المستخدم100% معتمة (أي، خاصية Opacity لديها قيمة 1).
الوظيفة الإضافية واجهة المستخدم يجب أن تظهر أعلى بعض عناصر WPF في نفس المستوى الإطار الأعلى.
لا يوجد جزء من واجهة المستخدم الخاص بالوظيفة الإضافية يمكن عرضه باستخدام VisualBrush. بدلاً من ذلك، الوظيفة الإضافية قد تستغرق لقطة من واجهة المستخدم المُنشَئ لإنشاء صورة نقطية التي يمكن تمريرها إلى التطبيق المضيف باستخدام الأساليب المعرّفة من قِبل العقد.
لا يمكن قراءة ملفات الوسائط من MediaElement في الوظيفة الإضافية واجهة المستخدم.
أحداث الماوس التي تم إنشاؤها من أجل الوظيفة الإضافية واجهة المستخدم لا يتم تلقيها أو رفعها بواسطة التطبيق المضيف و خاصية IsMouseOver للتطبيق المضيف واجهة المستخدم لديها قيمة false.
عند نقل التركيز بين عناصر التحكم في الوظيفة الإضافية واجهة المستخدم، أحداث GotFocus و LostFocus لا يتم تلقيها أو رفعها بواسطة التطبيق المضيف.
جزء التطبيق المضيف الذي يحتوي على الوظيفة الإضافية واجهة المستخدم يظهر باللون الأبيض عند طباعته.
كافة المرسلين (راجع Dispatcher) الذي تم إنشائهم بواسطة الوظيفة الإضافية واجهة المستخدم يجب أن يتم إيقافها يدوياً قبل أن يتم إلغاء تحميل الوظيفة الإضافية المالكة في حالة استمرار التطبيق المضيف في التنفيذ. يمكن للعقد تنفيذ الأساليب التي تسمح للتطبيق المضيف أن يشير للوظيفة الإضافية قبل إلغاء تحميل الوظيفة الإضافية و بالتالي السماح للوظيفة الإضافية واجهة المستخدم أن تقوم بإيقاف المرسلين الخاصين به.
إذا كانت الوظيفة الإضافية واجهة المستخدم هي InkCanvas أو تحتوي على InkCanvas، لا يمكنك إلغاء تحميل الوظيفة الإضافية.
أمثلية الأداء
افتراضياً، عند استخدام عدة مجالات تطبيق, تجميعات .NET Framework المتنوعة المطلوبة من قبل كل تطبيق يتم تحميلها في ذلك المجال للتطبيق. نتيجة لذلك، قد يؤثر الوقت المطلوب لإنشاء مجالات التطبيقات الجديدة و بدء تشغيل تطبيقات في الأداء. مع ذلك، .NET Framework يوفر طريقة لك لتقليل أوقات البداية بإرشاد التطبيقات لمشاركة التجميعات عبر مجالات التطبيق إذا كان بالفعل تم تحميلهم. تقوم بذلك باستخدام سمة LoaderOptimizationAttribute, التي يجب تطبيقها إلى أسلوب نقطة الإدخال (Main). في هذه الحالة، يجب استخدام التعليمات البرمجية فقط لتنفيذ تعريف التطبيق الخاص بك (راجع نظرة عامة حول إدارة التطبيق).
راجع أيضًا:
المرجع
المبادئ
الوظائف الإضافية ووحدات الامتداد