كيف تتعامل مع ActiveX / OCX اليوم - جدول قرار للإبقاء / التغليف / الاستبدال

المشاريع التي لا يزال يُذكر فيها ActiveX / OCX تأتي عادةً مع شيء من الثقل في الجوّ.

• تطبيقات VB6 أو C++ / MFC القديمة لا تزال قيد الاستخدام الفعليّ
• معدّات صناعيّة أو SDK لأجهزة قياس لا تكشف إلّا عن OCX
• تطبيق Web داخليّ لا يزال يفترض ActiveX ولا يستطيع الخروج من IE mode
• OCX واحد يعرقل الانتقال من 32-bit إلى 64-bit

لكن أيّاً من ردّتي الفعل التاليتين ليست جيّدة:

• “إنّه قديم، فلنرمِ كلّ شيء”
• “لا يزال يعمل، فلنحفظه إلى الأبد”

ما يهمّ أوّلاً هو ما إذا كان ذلك ActiveX / OCX مجرّد widget للواجهة، أم أنّه حدّ يحمل سلوكاً حقيقيّاً للأعمال أو للمعدّات.

ينظّم هذا المقال كيفيّة اتّخاذ القرار بين الإبقاء والتغليف والاستبدال عند مواجهة ActiveX / OCX.

تشمل الأهداف النموذجيّة:

• تطبيقات سطح مكتب قديمة مبنيّة بـ VB6 / MFC / WinForms
• ترحيل تدريجيّ نحو C# / .NET
• شاشات قديمة تتضمّن WebBrowser أو IE mode
• تطبيقات Windows تعتمد على عناصر تحكّم ActiveX مقدّمة من بائعين

المحتويات

1. النسخة المختصرة
2. ما الذي يعنيه ActiveX / OCX في هذا المقال
3. جدول القرار الأوّل
   • 3.1. الصورة الإجماليّة
   • 3.2. متى تبقيه
   • 3.3. متى تغلّفه
   • 3.4. متى تستبدله
   • 3.5. الاعتماد على المتصفّح حالة خاصّة بذاتها
4. أسئلة تشوّش القرار
   • 4.1. هل هو مجرّد مكوّن واجهة، أم يحوي سلوكاً حقيقيّاً؟
   • 4.2. 32-bit / 64-bit وحدود العمليّات
   • 4.3. التسجيل والنشر والصلاحيّات والترخيص
   • 4.4. STA وحلقات الرسائل والـ callback
   • 4.5. هل السلوك قابل للملاحظة والاختبار؟
5. توصيات حسب الحالات النموذجيّة
   • 5.1. تطبيق سطح مكتب داخليّ مستقرّ
   • 5.2. الرغبة في إدخال OCX بـ 32-bit إلى الجانب 64-bit
   • 5.3. شاشات مبنيّة حول افتراضات IE / WebBrowser
   • 5.4. ActiveX يخفي تحكّماً بأجهزة أو سلوكاً خاصّاً
6. أنماط مضادّة شائعة
7. قائمة فحص لبدء الترحيل
8. دليل قاعدة عامّة تقريبيّة
9. هذا النوع من الاستشارات يلائم
10. الخلاصة

1. النسخة المختصرة

• أوّل ما يجب الحكم عليه ليس ما إذا كان المكوّن “قديماً”، بل ما المسؤوليّة التي يحملها
• إذا كان مجرّد مكوّن واجهة، فإنّ الاستبدال يكون سهلاً نسبيّاً
• إذا كان يحمل تحكّماً بأجهزة، أو منطق تقارير، أو صيغاً خاصّة، أو سلوكاً تجاريّاً متراكماً، فإنّ تغليفه أوّلاً يكون أكثر أماناً عادةً
• إذا كان مستقرّاً داخل تطبيق سطح مكتب وسطح التغيير صغيراً، فإنّ إبقاءه يمكن أن يكون قراراً منطقيّاً تماماً
• الاعتماد على ActiveX من جانب المتصفّح يجب أن يُعامل عادةً كمشكلة استبدال أوّلاً
• لا يمكن تحميل OCX بـ 32-bit داخل عمليّة 64-bit بشكل in-proc
• التسجيل والنشر والصلاحيّات والترخيص وافتراضات الـ threading كثيراً ما تكون أصعب من الكود نفسه
• “إعادة كتابة كلّ شيء” و”تجميده إلى الأبد لأنّه مخيف” كلاهما خيارات عالية المخاطر

الترتيب العمليّ عادةً هو:

1. ما الذي يملكه هذا الـ OCX فعلاً؟
2. هل يحتاج فعلاً إلى العمل في العمليّة ذاتها؟
3. هل ستوقف الخطّةَ مسائلُ bitness أو التسجيل أو الاعتماد على المتصفّح؟
4. هل نحتاج إلى جعل السلوك قابلاً للاختبار قبل استبداله؟

2. ما الذي يعنيه ActiveX / OCX في هذا المقال

يستخدم هذا المقال المصطلحات بمعنى عمليّ موجّه نحو المشاريع:

من الناحية الدقيقة، ActiveX و COM ليسا الشيء ذاته. لكنّ نقاط الألم العمليّة متشابهة جدّاً:

• bitness
• التسجيل والنشر
• افتراضات المضيف / الحاوية
• افتراضات STA والـ callback
• الاعتماد على المتصفّح

لذا يجمعها هذا المقال معاً من زاوية اتّخاذ القرار العمليّ.

3. جدول القرار الأوّل

3.1. الصورة الإجماليّة

هذا الجدول الأوّل يعطي بالفعل الاتّجاه الصحيح في كثير من الحالات.

flowchart TD
    start["You found ActiveX / OCX"] --> q1{"Browser-dependent?"}
    q1 -- "Yes" --> p1["Prioritize replacement<br/>IE mode is a bridge, not the destination"]
    q1 -- "No" --> q2{"Mostly a UI widget?"}
    q2 -- "Yes" --> q3{"Is there a practical replacement?"}
    q3 -- "Yes" --> p2["Consider replacement"]
    q3 -- "No" --> p3["Wrap first and organize the boundary"]
    q2 -- "No" --> q4{"Does it carry device logic / proprietary behavior / report logic?"}
    q4 -- "Yes" --> p4["Wrap first<br/>prepare tests, then replace step by step"]
    q4 -- "No" --> q5{"Are registration / bitness / deployment painful?"}
    q5 -- "Yes" --> p5["Reconsider the architecture<br/>out-of-proc / helper process / Reg-Free COM"]
    q5 -- "No" --> p6["Keeping it is a realistic option"]

3.2. متى تبقيه

ليس كلّ ActiveX / OCX يجب أن يصبح فوراً مشروع استبدال. الإبقاء عليه يمكن أن يكون أرخص إجابة صحيحة عندما تبدو الظروف هكذا:

• الاستخدام محصور والبيئة مضبوطة
• عنصر التحكّم مستقرّ اليوم والتغييرات المطلوبة صغيرة
• البائع لا يزال موجوداً، أو يمكنك على الأقلّ الحفاظ على الحدّ الأدنى داخليّاً
• ليست تبعيّة من جانب المتصفّح بل مكوّن مستضاف على سطح المكتب
• لا تحتاج بعدُ إلى تغيير افتراض bitness

لكنّ الإبقاء عليه لا يعني تركه دون مساس إلى الأبد. إذا أبقيته، فعلى الأقلّ:

• وثّق نظام التشغيل المدعوم و bitness و DLL المطلوبة وخطوات التسجيل
• توقّف عن الاعتماد على ذاكرة الأشخاص في الإعداد؛ انقل النشر نحو سكربتات أو مثبّتات
• جهّز smoke test على بيئة نظيفة
• اجمع استدعاءات عنصر التحكّم خلف جزء أضيق من التطبيق بدلاً من نثرها في كلّ مكان

أسوأ نمط هو “إنّه يعمل، فلا يلمسه أحد” لعشر سنوات حتّى لا يستطيع أحد بعدها شرح افتراضاته الحقيقيّة.

3.3. متى تغلّفه

في العمل الحقيقيّ، هذا غالباً ما يكون الخيار الأكثر قيمةً.

“التغليف” يعني إحاطة ActiveX / OCX داخل حدّ ضيّق وكشف API أنظف أو تجريد على جانب الشاشة لباقي النظام المحدَّث.

هذا قويّ لأنّك إذا قفزت إلى إعادة كتابة كاملة بينما لا يزال سلوك المكوّن القديم ضبابيّاً، يصبح المشروع بسرعة جهداً مزدوجاً من:

• اكتشاف السلوك القديم
• إعادة إنشائه
• تصحيح الحدّ

التغليف أوّلاً أكثر أماناً.

تشمل أنماط التغليف العمليّة:

أهمّ انضباط هنا هو عدم نسخ 200 طريقة قديمة واحدة تلو الأخرى إلى طبقة جديدة. ذلك يستورد ببساطة قيود التصميم القديم إلى الكود الجديد.

عند التغليف، يساعد كثيراً أن:

• تفضّل طرقاً ذات حبيبات خشنة
• توقف كود الواجهة عن التحدّث مع الـ OCX مباشرةً
• تجمع السجلّات عند الحدّ
• تحدّد مسؤوليّة timeout / retry / ترجمة الاستثناءات عند الحدّ
• تكشف واجهة يمكن إعادة تنفيذها لاحقاً دون الـ OCX خلفها

3.4. متى تستبدله

الاستبدال أسهل عندما تكون المشكلة في معظمها قِدَم سطحيّ.

أمثلة جيّدة:

• المكوّن في معظمه widget للواجهة
• لدى البائع بالفعل بديل حديث على جانب .NET / WPF / WebView2
• الألم الرئيسيّ هو الاعتماد على المتصفّح
• التسجيل والتوقيعات وصلاحيّات المسؤول وإعدادات الأمان تعرقل العمل باستمرار
• لديك ما يكفي من الاختبارات أو السيناريوهات التجاريّة الملاحَظة لتأكيد سلوك الاستبدال

النسخة الخطرة هي رؤية شيء يبدو قديماً وافتراض أنّ كلّ شيء يمكن استبداله “كمجرّد تحديث للواجهة”، رغم أنّه يحمل سرّاً سلوك أجهزة أو منطق تقارير أو عقد بيانات خاصّاً.

إذا استبدلت، فإنّ البدء من جانب الواجهة غالباً ما يكون أكثر أماناً:

• grids
• calendars
• tree controls
• مناطق عرض المتصفّح
• مساعِدات إدخال بسيطة

تلك مختلفة جدّاً عن:

• عناصر تحكّم ActiveX لتحكّم بالمعدّات مقدّمة من البائع
• عناصر تحكّم تقارير أو طباعة بمنطق صيغ مدمج
• عناصر تحكّم تقرأ وتكتب ملفّات بصيغ خاصّة
• عناصر تحكّم بافتراضات COM callback و threading مدمجة فيها

سوء الحكم على هذا الفرق يدمّر التقديرات بسرعة كبيرة.

3.5. الاعتماد على المتصفّح حالة خاصّة بذاتها

هذا يحتاج إلى معالجة منفصلة.

ActiveX من جانب المتصفّح له مستقبل بعيد المدى أضعف بكثير من OCX على سطح المكتب المستضاف في عمليّة مضبوطة.

السبب مباشر:

• Microsoft Edge بحدّ ذاته لا يدعم ActiveX
• IE mode يمكن أن يبقي بعض ميزات حقبة IE حيّة للمواقع المهيّأة، بما في ذلك بعض سلوك ActiveX
• لكنّ تلك استراتيجيّة توافق، لا اتّجاه منتج قويّ بعيد المدى

تظهر القضيّة العمليّة ذاتها مع عنصر التحكّم القديم WebBrowser المدمج في تطبيقات Windows. إذا كانت الحاجة الحقيقيّة هي “عرض محتوى ويب”، فإنّ التطوير الجديد يجب أن ينظر عادةً إلى WebView2 أوّلاً.

لكنّ WebView2 ليس بديلاً جاهزاً لكلّ افتراضات حقبة IE. قد يتطلّب الترحيل أيضاً إعادة تصميم:

• افتراضات IE DOM
• الاعتماد على ActiveX
• window.external
• افتراضات منطقة الأمان والإنترانت

لذا فإنّ ActiveX من جانب المتصفّح ليس عادةً مشكلة “تبديل محرّك العرض” بسيطة. إنّه غالباً مشكلة إعادة تصميم حدّ المتصفّح.

4. أسئلة تشوّش القرار

4.1. هل هو مجرّد مكوّن واجهة، أم يحوي سلوكاً حقيقيّاً؟

هذا أهمّ سؤال.

شبكة قديمة أو تقويم قديم غالباً ما يكون في معظمه عن المظهر وتوافق الأحداث. لكنّ بعض عناصر التحكّم التي تبدو “مجرّد widget للواجهة” تحمل في الواقع سلوكاً عميقاً، مثل:

• أوامر الجهاز
• التعامل مع الـ retry والـ timeout
• افتراضات ترتيب الأحداث
• توليد التقارير
• I/O بصيغ خاصّة

إعادة تنفيذ ذلك فوراً غالباً ما تتحوّل إلى مشروع اكتشاف للمواصفات. التغليف أوّلاً أكثر أماناً بكثير هناك.

4.2. 32-bit / 64-bit وحدود العمليّات

هذا غالباً ما يُغفل عنه، لكنّه قيد تقنيّ جوهريّ.

OCX يعمل in-proc يجب أن يطابق bitness عمليّة المضيف. لذا لا يمكنك ببساطة تحميل OCX بـ 32-bit في عمليّة 64-bit.

تصبح الخيارات العمليّة عندئذٍ:

• إبقاء التطبيق المضيف بـ 32-bit في الوقت الحاليّ
• عزل الـ OCX في helper / LocalServer بـ 32-bit والاتّصال من جانب 64-bit عبر IPC أو COM out-of-proc
• إزالة تلك التبعيّة تدريجيّاً حيث أمكن

“Any CPU سيجعل الأمور تعمل بطريقة ما” نادراً ما يكون إجابة حقيقيّة هنا.

4.3. التسجيل والنشر والصلاحيّات والترخيص

أحياناً يكون الكود قابلاً للاستدعاء تقنيّاً، لكنّ المشروع الحقيقيّ لا يزال يفشل في النشر.

نقاط المتاعب النموذجيّة:

• خطوات regsvr32 تعتمد على الإنسان
• وضع DLL تابعة ضمنيّ
• متطلّبات صلاحيّات مسؤول مخفيّة
• افتراضات ترخيص بائع مختلفة بين runtime / design-time
• “يعمل على جهاز التطوير، يفشل على بيئة نظيفة”

لهذا السبب فإنّ ترحيل ActiveX / OCX ليس فقط مشكلة تنفيذ، بل أيضاً مشكلة تصميم نشر.

4.4. STA وحلقات الرسائل والـ callback

ActiveX / OCX ليس مجرّد “استدعاء DLL”. قد يحمل افتراضات نموذج threading لـ COM وحلقة رسائل.

انتبه لحالات مثل:

• يكون مستقرّاً فقط عند إنشائه على UI thread
• يفترض STA لكنّ شخصاً يستدعيه بإهمال من MTA
• استدعاء متزامن يطلق callback يعود إلى تطبيقك
• الـ thread الذي يستقبل الأحداث يُترك غامضاً

تظهر هذه المشكلات أوّلاً غالباً على شكل “يتجمّد أحياناً” أو “أحياناً لا يصل الحدث أبداً”. لكنّ السبب الحقيقيّ غالباً هو افتراض threading منتهَك.

4.5. هل السلوك قابل للملاحظة والاختبار؟

الاستبدال صعب ليس فقط لأنّ الكود قديم. إنّه صعب لأنّك غالباً لا تعرف بعدُ ما الذي يعنيه فعلاً “يتصرّف بالطريقة ذاتها”.

حتّى القليل من هذه يساعد كثيراً:

• smoke tests لسيناريوهات تشغيل مهمّة
• عيّنات إدخال وإخراج
• عيّنات تقارير أو حالات شاشة ملتقطة
• السلوك المتوقّع على مسارات الفشل
• سجلّات لسيناريوهات timeout والمعدّات المنفصلة

خاصّة مع المعدّات والتقارير، السلوك الحقيقيّ للنظام غالباً ما يكون أكثر موثوقيّة من أيّ مواصفات مكتوبة. دون قابليّة الملاحظة، يتحوّل الاستبدال إلى تنقيب أثريّ.

5. توصيات حسب الحالات النموذجيّة

5.1. تطبيق سطح مكتب داخليّ مستقرّ

التوصية: الميل إلى الإبقاء.

إذا كان:

• التطبيق داخليّ فقط
• البيئة مضبوطة
• الـ OCX مستخدم في عدد قليل فقط من الشاشات
• طلب التغيير محدود

فمن الأكثر معقوليّة عادةً عدم اقتلاعه فوراً.

ومع ذلك، حتّى لو أبقيته، فمن المفيد جمع استخدامه خلف حدّ.

يصبح الموقف العمليّ:

• أبقِه الآن
• لكن نظّم الحدّ
• بحيث يبقى الاستبدال ممكناً لاحقاً

5.2. الرغبة في إدخال OCX بـ 32-bit إلى الجانب 64-bit

التوصية: التغليف / تغيير المعماريّة.

هذا هو المكان الذي يفشل فيه السير المباشر عادةً، لأنّ OCX in-proc بـ 32-bit لا يستطيع العيش داخل عمليّة 64-bit.

الشكل العمليّ غالباً هو:

• ضع الـ OCX خلف عمليّة helper أو LocalServer بـ 32-bit
• تحدّث إليه عبر API أكثر خشونة
• تجنّب إعادة توجيه كلّ استدعاء طريقة صغير عبر حدّ العمليّة

sequenceDiagram
    participant App as 64-bit .NET app
    participant Bridge as 32-bit helper / LocalServer
    participant Ocx as 32-bit OCX

    App->>Bridge: request via coarse API
    Bridge->>Ocx: in-proc call
    Ocx-->>Bridge: result / event
    Bridge-->>App: translated result

5.3. شاشات مبنيّة حول افتراضات IE / WebBrowser

التوصية: الاستبدال أوّلاً.

هذه منطقة يتباعد فيها بشدّة “يعمل الآن” و”صحّيّ للمستقبل”. يمكن لـ IE mode أن يبقي نظاماً حيّاً، لكنّه لا يزال توافق حقبة IE.

لذا فإنّ الموقف العمليّ هو:

• أبقِ الأعمال تعمل الآن
• لا تخلط ذلك بمعماريّة دائمة
• قيّم البدائل مثل WebView2 أو إعادة كتابة ويب حقيقيّة أو تصميم هجين من واجهة أصليّة + ويب

5.4. ActiveX يخفي تحكّماً بأجهزة أو سلوكاً خاصّاً

التوصية: التغليف أوّلاً.

هذا النوع من المكوّنات غالباً ما يكون أعمق بكثير ممّا يبدو. حتّى لو كانت الوثائق الرسميّة شحيحة، فإنّ سنوات من التشغيل قد تكون قد رسّخت افتراضات حول:

• سلوك timeout
• توقيت إعادة الاتّصال
• ترتيب الأحداث
• حلول بديلة خاصّة بالجهاز
• تفسير الأخطاء والاستثناءات

محاولة إعادة كتابة ذلك دفعةً واحدةً غالباً ما تحرق مرحلة اختبار القبول.

لذا فإنّ التسلسل الأكثر أماناً هو:

1. عزل المكوّن الموجود خلف حدّ
2. إضافة logging وقابليّة ملاحظة
3. جمع سيناريوهات اختبار وأنماط أجهزة حقيقيّة
4. ثمّ فقط استبدال الأجزاء خطوةً خطوةً

6. أنماط مضادّة شائعة

7. قائمة فحص لبدء الترحيل

لعمل ActiveX / OCX، يسير الأمر عادةً بشكل أفضل إذا قمت بالجرد أوّلاً بدلاً من القفز مباشرةً إلى التنفيذ.

الترتيب العمليّ غالباً هو:

1. جرد مجموعة OCX / DLL
   • اسم الملفّ، الإصدار، ProgID، CLSID، البائع، الترخيص
2. جرد أماكن استخدامه
   • الشاشات، الوظائف، التقارير، الأجهزة، الـ batches، أتمتة Office، وما إلى ذلك
3. تأكيد ظروف المضيف و bitness
   • 32-bit / 64-bit، in-proc / out-of-proc، افتراضات STA، الاعتماد على المتصفّح
4. تأكيد ظروف النشر
   • طريقة التسجيل، DLL تابعة، صلاحيّات المسؤول، إمكانيّة التكرار على جهاز نظيف
5. بناء smoke tests
   • ليس فقط المسارات العاديّة، بل أيضاً مسارات الفشل والـ timeout والجهاز المنفصل
6. إنشاء حدّ
   • adapter، service، facade، جسر عمليّة helper، وما إلى ذلك
7. اختبار شاشة صغيرة واحدة / وظيفة واحدة / مسار جهاز واحد أوّلاً
8. توسيع قرارات الإبقاء / التغليف / الاستبدال انطلاقاً من الحدود التي تنجح

تخطّي هذه الخطوات يجعل من الأصعب بكثير لاحقاً حتّى شرح ما الذي كان صعباً فعلاً.

8. دليل قاعدة عامّة تقريبيّة

عند الشكّ، قرّر أوّلاً ما إذا كان المكوّن مجرّد واجهة أم حدّاً ثقيل السلوك.

9. هذا النوع من الاستشارات يلائم

هذا الموضوع غالباً ما ينتج قيمة حتّى قبل بدء التنفيذ، ببساطة من خلال تنظيم الاتّجاه.

على سبيل المثال:

• تحديد أيّ OCX يجب فعلاً استبداله أوّلاً
• فرز فخاخ 32-bit / 64-bit مسبقاً
• الإبقاء فقط على نقطة دخول COM مع تحديث الداخل
• مقارنة استراتيجيّات البقاء مقابل الترحيل لعنصر تحكّم تخلّى عنه البائع
• تحديد من أين يمكن نزع اعتماد IE / WebBrowser أوّلاً
• فصل شاشة واحدة أو وظيفة واحدة فقط بأمان أوّلاً

في هذه المشاريع، كيف تقطع الحدّ غالباً ما يكون شرط النصر الحقيقيّ.

10. الخلاصة

التعامل مع ActiveX / OCX ليس عن حبّ القديم أو كرهه. إنّه عن فهم:

1. ما إذا كان المكوّن widget للواجهة أم حدّاً ثقيل السلوك
2. ما إذا كان يجب فعلاً أن يبقى في العمليّة ذاتها
3. ما إذا كانت bitness أو التسجيل أو الاعتماد على المتصفّح أو الترخيص ستوقفك
4. ما إذا كان السلوك الحاليّ قابلاً للملاحظة بما يكفي للاستبدال بأمان

بمجرّد رؤية هذه الأربعة، يصبح خيار الإبقاء / التغليف / الاستبدال أوضح بكثير:

• أبقِه إذا كان مستقرّاً والعمر المتبقّي قابلاً للإدارة
• غلّفه إذا كنت تريد تحديثاً آمناً حوله
• استبدله عندما تكون المشكلة في معظمها على مستوى الواجهة أو الاعتماد على المتصفّح
• غلّف أوّلاً عندما يحوي كتلة كثيفة من السلوك والعقود

المكوّنات القديمة ليست مجرّد “كود قديم”. إنّها غالباً قطع أثريّة مليئة بالتاريخ والعقود الضمنيّة.

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.