איך מתייחסים היום ל-ActiveX /‏ OCX — טבלת החלטה: לשמר, לעטוף או להחליף

פרויקטים שבהם עולות המילים ActiveX /‏ OCX, בדרך כלל האווירה קצת כבדה.

• אפליקציית VB6 או C++‏ /‏ MFC ישנה עדיין בשימוש
• ה-SDK של ציוד תעשייתי או מכשיר מדידה מציע רק OCX
• אתר פנים-ארגוני שמניח ActiveX, ואי אפשר לצאת ממצב IE
• רוצים לעבור מ-32bit ל-64bit, אבל OCX בודד מסרב

אבל גם “זה ישן אז זורקים הכול” וגם “זה עובד אז שומרים לנצח” הן גישות רשלניות. החשוב הוא להבחין אם ה-ActiveX /‏ OCX הוא סתם רכיב UI, או שהוא ממשק גבול שנושא בתוכו מפרט עסקי או מפרט של ציוד.

המאמר הזה מסדר בסדר קל לקבלת החלטה, מה לבחור כשמוצאים ActiveX /‏ OCX — לשמר, לעטוף או להחליף.

המקרים הרלוונטיים הם, לדוגמה:

• אפליקציות desktop קיימות מסוג VB6 /‏ MFC /‏ WinForms
• מעבר הדרגתי ל-C# /‏ .NET
• מסכי legacy שכוללים WebBrowser / מצב IE
• אפליקציות Windows שכוללות פקדי ActiveX של ספקים

תוכן עניינים

1. קודם כול, המסקנה (במשפט אחד)
2. ActiveX /‏ OCX במאמר הזה
3. קודם כול, טבלת ההחלטה
   • 3.1. התמונה הכוללת
   • 3.2. החלטה לשמר
   • 3.3. החלטה לעטוף
   • 3.4. החלטה להחליף
   • 3.5. תלות בדפדפן נשקלת בנפרד
4. נקודות שקל לטעות בהן
   • 4.1. רכיב UI, או רכיב שנושא מפרט
   • 4.2. ‏32bit /‏ 64bit וגבול התהליכים
   • 4.3. רישום, הפצה, הרשאות, רישיונות
   • 4.4. STA / לולאת הודעות / callback
   • 4.5. יש בדיקות? אפשר לצפות?
5. המלצות לפי דפוסים אופייניים
   • 5.1. אפליקציית desktop פנים-ארגונית שיציבה כרגע
   • 5.2. רוצים להעביר OCX‏ 32bit לצד 64bit
   • 5.3. מסך שמניח IE /‏ WebBrowser
   • 5.4. ActiveX עם בקרת התקן או מפרט ייחודי
6. אנטי-דפוסים נפוצים
7. רשימת בדיקה להתחלת מעבר
8. חלוקה גסה בין המצבים
9. סיכום
10. סוג ההתייעצות שמתאים לזה
11. מקורות

מפת הידע של המאמר

בפועל, ActiveX משמש כמילה שמתייחסת לבקר מבוסס COM ולנכסים שסביבו, ו-OCX הוא הקובץ שמכיל את הישות הזו בפועל. ‏OCX שפועל in-proc חייב להתאים בהרכב הביטים (32bit/‏64bit) לתהליך המארח, וכדי לחצות את המגבלה הזו עוברים לתהליך נפרד כמו COM LocalServer שעוקף את חומת ה-bitness. בצד הדפדפן, גוף Microsoft Edge עצמו לא מחזיק ActiveX, וגם WebView2 לא יכול לרשת כמו שהוא תלות ב-ActiveX או סקריפט שמניח DOM של IE, ולכן מצב IE ממוקם כאמצעי הארכת חיים. אמצעי העטיפה כוללים אירוח כ-Windows Forms דרך AxHost ו-Aximp, פתרון ללא רישום ברג’יסטרי דרך Reg-Free COM, ורישום OCX דרך regsvr32 — כל אלה מניחים כתשתית מזהים ומידע טיפוסים כמו CLSID, ‏ProgID וספריית הטיפוסים.

flowchart LR
    accTitle: מפת הידע של ההחלטה בין להשאיר, לעטוף או להחליף ActiveX/‏OCX
    accDescr: תרשים שמראה ש-ActiveX ו-OCX מבוססים על COM; את אילוץ אי-ההתאמה ב-bitness ואת העקיפה שלו באמצעות תהליך נפרד; את יחסי אי-ההתאמה עם תלות בדפדפן (‏Edge, ‏מצב IE, ‏WebBrowser, ‏WebView2); ואיך אמצעי העטיפה (‏AxHost/‏Aximp/‏Reg-Free COM/‏LocalServer) קשורים ל-CLSID, ל-ProgID ולספריית הטיפוסים.
    activex["ActiveX"]
    ocx["OCX"]
    com["‏COM (Component Object Model)"]
    com_apartment_model["מודל ה-apartment של COM‏ (STA/MTA)"]
    bitness_match_requirement["דרישת התאמת bitness"]
    com_localserver["‏COM LocalServer (שרת COM בתהליך נפרד)"]
    aximp["AxImp(ActiveX Control Importer)"]
    axhost["AxHost"]
    windows_forms["Windows Forms"]
    clsid["CLSID(Class ID)"]
    progid["ProgID(Programmatic Identifier)"]
    vb6["Visual Basic 6.0(VB6)"]
    type_library["ספריית טיפוסים (TLB)"]
    ie_mode["מצב IE"]
    microsoft_edge["Microsoft Edge"]
    webbrowser_control["פקד WebBrowser"]
    webview2["Microsoft Edge WebView2"]
    reg_free_com["‏Reg-Free COM (COM ללא רישום)"]
    regsvr32["regsvr32"]
    mfc["MFC(Microsoft Foundation Classes)"]
    webview2_runtime["WebView2 Runtime"]
    activex -->|"משתמש ב"| com
    ocx -->|"מממש את"| activex
    ocx -.->|"מחייב"| com_apartment_model
    ocx -->|"מחייב"| bitness_match_requirement
    com_localserver -->|"מצמצם"| bitness_match_requirement
    aximp -->|"משתמש ב"| ocx
    aximp -->|"משתמש ב"| axhost
    axhost -->|"מממש את"| activex
    axhost -->|"מחייב"| windows_forms
    com_localserver -->|"מחייב"| clsid
    progid -->|"מחייב"| clsid
    vb6 -->|"מחייב"| type_library
    aximp -->|"מחייב"| type_library
    ie_mode -->|"מחייב"| microsoft_edge
    microsoft_edge -.->|"אינו מתיישב עם"| activex
    ie_mode -->|"משתמש ב"| activex
    webbrowser_control -.->|"משתמש ב"| activex
    webview2 -->|"אינו מתיישב עם"| activex
    webview2 -.->|"יורש את"| webbrowser_control
    reg_free_com -->|"מחייב"| clsid
    reg_free_com -.->|"מחייב"| progid
    ocx -->|"מוגדר באמצעות"| regsvr32
    mfc -.->|"משתמש ב"| com
    webview2 -->|"מחייב"| webview2_runtime

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 24, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

1. קודם כול, המסקנה (במשפט אחד)

• כשרואים ActiveX /‏ OCX, השאלה הראשונה שצריך לשאול היא לא “האם זה ישן”, אלא מה הרכיב הזה בעצם אחראי עליו
• אם זה סתם רכיב UI, ההחלפה יחסית קלה
• אם הוא נושא בקרת התקן, דוחות, פורמט קובץ ייחודי או הרגלי הפעלה ישנים — בטוח יותר קודם לעטוף מאשר לממש מחדש ישר
• אם הוא יציב ב-desktop ותחום השינוי בו קטן, גם ההחלטה לשמר סבירה לגמרי
• תלות ב-ActiveX בדפדפן אפשר להאריך חיים, אבל העתיד שלה דל — עדיף להסתכל מתוך עדיפות להחלפה
• אי אפשר לטעון OCX‏ 32bit לתוך תהליך 64bit ישירות. זו מגבלה שלא עוברים בכוח רצון
• חיכוך שאינו טכני — רישום, DLL תלויים, הרשאות מנהל, רישיונות, STA /‏ MTA — נוטה להיות המכשול הגדול
• גם “סתם לכתוב הכול מחדש” וגם “להקפיא לנצח כי זה מפחיד” הן בחירות עם שיעור תקלות גבוה

בקיצור, סדר ההחלטה הוא:

1. מה יש בתוך ה-OCX הזה
2. האם צריך להשתמש בו באותו תהליך
3. האם זה נתקע ב-32bit /‏ 64bit, רישום או תלות בדפדפן
4. האם צריך קודם ליצור גבול הניתן לבדיקה, ורק אז להחליף

בסדר הזה, קל בהרבה לסדר את זה.

flowchart TB
    accTitle: סדר ההחלטה
    accDescr: תרשים המראה שהסדר לבדיקה הוא מה יש בתוך ה-OCX, האם צריך אותו תהליך, האם 32bit או 64bit או רישום או תלות בדפדפן חוסמים, והאם צריך ליצור גבול הניתן לבדיקה לפני שמחליפים.
    s1["מה יש בתוך ה-OCX"] --> s2["האם צריך אותו תהליך"]
    s2 --> s3["האם bitness, רישום או דפדפן חוסמים"]
    s3 --> s4["ליצור גבול לפני שמחליפים"]

איור 1: לא “האם זה ישן” — בסדר הזה קל יותר לסדר את ההחלטה בין לשמר, לעטוף או להחליף.

2. ActiveX /‏ OCX במאמר הזה

קודם כול, נבהיר איך נעשה שימוש במילים במאמר הזה.

בהגדרה מדויקת, ActiveX ו-‏COM אינם אותו הדבר. אבל הנקודות שמקשות בעבודה בפועל דומות מאוד.

• האם ה-32bit /‏ 64bit מתאימים
• איך מפיצים את הרישום וה-DLL התלויים
• באיזה host / container זה רץ
• האם STA, לולאת הודעות או callback לא חוסמים
• האם לא נשארה תלות בדפדפן

המאמר הזה מרכז את נקודות ההחלטה המעשיות האלה.

flowchart TB
    accTitle: נקודות שמקשות בעבודה בפועל
    accDescr: תרשים המראה שגם אם ActiveX ו-COM אינם אותו הדבר במדויק, הנקודות שמקשות בעבודה בפועל דומות מאוד: התאמת bitness, הפצת רישום ו-DLL, זהות ה-host, והנחות STA ו-callback שמובילות לפעמים לתלות בדפדפן.
    ax["מקרה ActiveX / OCX"] --> p1["האם bitness מתאים"]
    ax --> p2["הפצת רישום ו-DLL תלויים"]
    ax --> p3["באיזה host זה רץ"]
    ax --> p4["הנחות STA ו-callback"]
    p4 -.-> p5["האם נשארה תלות בדפדפן"]

איור 2: גם אם ActiveX ו-COM שונים בהגדרה מדויקת, הנקודות שמקשות בעבודה בפועל מתרכזות באזור הזה.

בנוסף, נסכם מראש את הקיצורים שיופיעו בהמשך כמובנים מאליהם. גם אם בפרק 7, ברשימת הבדיקה, כתוב “למפות ProgID ו-CLSID”, בלי להבין את זה קשה להתקדם.

3. קודם כול, טבלת ההחלטה

3.1. התמונה הכוללת

אם מסתכלים על הטבלה הזו קודם, רוב הכיוון כבר נקבע.

flowchart TD
    accTitle: תרשים ההחלטה המלא - לשמר, לעטוף או להחליף
    accDescr: תרשים המראה שההסתעפות הראשונה היא תלות בדפדפן, ואם כן עדיפות להחלפה כי מצב IE הוא רק הארכת חיים; אחרת בודקים אם זה בעיקר רכיב UI עם תחליף שקול ואז שוקלים החלפה או קודם עטיפה; אם לא, בודקים אם יש בקרת התקן או מפרט ייחודי ואז קודם עוטפים ומכינים בדיקות; ואם לא, בודקים אם רישום, bitness או הפצה כואבים ואז בוחנים מחדש את המבנה, אחרת ההחלטה לשמר סבירה.
    start["יש ActiveX / OCX"] --> q1{"תלות בדפדפן?"}
    q1 -- "כן" --> p1["עדיפות להחלפה — מצב IE הוא רק הארכת חיים"]
    q1 -- "לא" --> q2{"בעיקר רכיב UI?"}
    q2 -- "כן" --> q3{"יש תחליף שקול?"}
    q3 -- "כן" --> p2["לשקול החלפה"]
    q3 -- "לא" --> p3["קודם לעטוף ולסדר את הגבול"]
    q2 -- "לא" --> q4{"יש בקרת התקן, מפרט ייחודי או לוגיקת דוחות?"}
    q4 -- "כן" --> p4["קודם לעטוף — להכין בדיקות ואז להחליף בהדרגה"]
    q4 -- "לא" --> q5{"רישום, bitness או הפצה כואבים?"}
    q5 -- "כן" --> p5["בחינה מחדש של המבנה — לשקול out-of-proc, חיבור לתהליך נפרד או Reg-Free COM"]
    q5 -- "לא" --> p6["גם ההחלטה לשמר ריאלית"]

איור 3: ההסתעפות הראשונה היא תלות בדפדפן, ואחר כך הכיוון נקבע לפי רכיב UI, קיום תחליף, או מפרט שהרכיב נושא.

מכאן נסקור כל דפוס בתורו.

3.2. החלטה לשמר

רק בגלל שזה ActiveX /‏ OCX, זה לא אומר שזה מיד מועמד להחלפה. אם מתקיימים תנאים כאלה, לרוב זול יותר פשוט לשמר:

• טווח השימוש סגור, וסביבת התפעול (הפצה פנים-ארגונית, צירוף לציוד וכדומה) קבועה
• הפקד יציב גם כרגע, ודרישות השינוי לא גדולות
• הספק עדיין פעיל, או שיש יכולת תחזוקה מינימלית בבית
• זה לא תלוי בדפדפן, ונשלם בתוך ה-host הקיים ב-desktop
• אין צורך לשנות בינתיים את הנחת ה-32bit /‏ 64bit

החשוב כאן הוא שלשמר לא שווה להזניח. אם משמרים, כדאי לעשות לפחות את זה:

• לתעד בכתב את מערכת ההפעלה הנתמכת, ה-bitness, ה-DLL התלויים הנדרשים ושלבי הרישום
• להעביר התקנה, רישום וביטול רישום לסקריפט או למתקין, ולא להסתמך על פתק ידני
• להכין smoke test בסביבה נקייה
• לרכז את הקריאות לפקד במקום אחד ככל האפשר, במקום לפזר אותן בכל האפליקציה

הכי גרוע הוא להמשיך 10 שנים עם “זה עובד אז לא נוגעים”, עד ששום אחד כבר לא יכול להסביר את ההנחות. ככל שבוחרים לשמר, הפיכת ההנחות לגלויות הופכת חשובה יותר.

flowchart TB
    accTitle: הפיכת ההנחות לגלויות כחלק מההחלטה לשמר
    accDescr: תרשים המראה שההחלטה לשמר אינה הזנחה אלא כוללת תיעוד ההנחות, הפיכת שלבי הרישום לסקריפט, הכנת smoke test בסביבה נקייה, וריכוז הקריאות במקום אחד.
    keep["ההחלטה לשמר"] --> d1["תיעוד ההנחות בכתב"]
    keep --> d2["הפיכת שלבי הרישום לסקריפט"]
    keep --> d3["הכנת smoke test"]
    keep --> d4["ריכוז הקריאות במקום אחד"]

איור 4: לשמר זה לא להזניח — ככל שבוחרים לשמר, כדאי יותר לחשוף את ההנחות.

3.3. החלטה לעטוף

בעבודה בפועל, זו הבחירה שדורשת הכי הרבה עבודה.

“לעטוף” כאן משמעו לכלוא את ה-ActiveX /‏ OCX בתוך גבול צר, ולהראות אותו לסביבה כ-API חדש או כרכיב מסך חדש.

זה יעיל מאוד. מכיוון שאם נכנסים למימוש מחדש מלא לפני שהתנהגות הרכיב הישן ברורה עד הסוף, בקלות נופלים לצרה כפולה — חפירת מפרט ושחזור תקלות. בטוח יותר לבודד קודם את הרכיב הישן, ולסדר רק את הגבול.

flowchart TB
    accTitle: המבנה של הבחירה לעטוף
    accDescr: תרשים המראה שכליאת ה-ActiveX / OCX בתוך גבול צר והצגתו לסביבה כ-API או כרכיב מסך חדש מונעים את הצרה הכפולה של חפירת מפרט ושחזור תקלות שנובעת ממימוש מחדש מלא לפני שההתנהגות ברורה.
    old["ActiveX / OCX"] --> wall["כליאה בתוך גבול צר"]
    wall --> api["הצגה כ-API חדש"]
    api --> app["הסביבה רואה רק את הצוהר החדש"]
    wall -.-> safe["הימנעות מחפירת מפרט ומשחזור כפול"]

איור 5: “לעטוף” הוא בידוד הרכיב הישן ובניית צוהר חדש, כשלב מקדים לפני מימוש מחדש מלא.

יש כמה תבניות לעטיפה.

אחרי שהכיוון נקבע, נכתוב גם מה הצעד הראשון.

מריצים את aximp מתוך Developer Command Prompt של Visual Studio.

aximp C:\path\to\MyControl.ocx

בעזרת זה נוצרים שני קבצים: runtime callable wrapper מסוג COM, ועוטף עבור Windows Forms שיורש מ-AxHost. שימו לב ששם הקובץ נקבע לפי ה-ProgID, לא לפי שם הקובץ המקורי. בדוגמה מהתיעוד של Microsoft, מ-msdxm.ocx יוצאים MediaPlayer.dll ו-AxMediaPlayer.dll. מוסיפים את השני כהפניה, ומדביקים את AxMediaPlayer על הטופס.

flowchart TB
    accTitle: מה aximp מייצר
    accDescr: תרשים המראה שהעברת OCX ל-aximp מייצרת שני קבצים — DLL עוטף מסוג COM ו-DLL עוטף שיורש מ-AxHost — כשהאחרון מתווסף כהפניה ומודבק על הטופס, ושם הקובץ נקבע לפי ProgID.
    ocx["ה-OCX היעד"] --> tool["הרצת aximp"]
    tool --> rcw["DLL עוטף מסוג COM"]
    tool --> ax["DLL עוטף שיורש מ-AxHost"]
    ax --> form["הוספה כהפניה והדבקה על הטופס"]
    tool -.-> name["שם הקובץ נקבע לפי ProgID"]

איור 6: הפלט של aximp הוא שני DLL, ומה שמדביקים על הטופס הוא העוטף שיורש מ-AxHost.

עבור Reg-Free COM, המניפסט הצדדי של האפליקציה במינימום נראה כך:

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" name="MyApp" version="1.0.0.0" />
  <file name="MyControl.ocx">
    <comClass
      clsid="{01234567-89AB-CDEF-0123-456789ABCDEF}"
      threadingModel="Apartment"
      progid="MyCompany.MyControl.1" />
  </file>
</assembly>

בשיטת ה-LocalServer, ברישום נכנס נתיב ה-EXE תחת HKEY_CLASSES_ROOT\CLSID\{CLSID}\LocalServer32. שרת EXE שנבנה עם ATL או MFC לרוב תומך, כמוסכמה, ברישום עצמי וביטול רישום עם MyServer.exe /regserver ו-/unregserver. אבל בגלל שהתצוגה ברישום נחלקת לפי bitness, חשוב תמיד לזכור ש-EXE של 32bit נרשם בצד ה-32bit של הרישום.

flowchart TB
    accTitle: רישום LocalServer ותצוגת הרישום
    accDescr: תרשים המראה שבשיטת LocalServer נרשם נתיב ה-EXE תחת LocalServer32 מתחת ל-CLSID, שאפשר לרשום עצמית עם המוסכמה של regserver, אבל תצוגת הרישום נחלקת לפי bitness ו-EXE של 32bit נרשם בצד ה-32bit.
    exe["שרת EXE"] --> reg["רישום נתיב תחת LocalServer32"]
    reg --> view{"מה ה-bitness של ה-EXE?"}
    view -->|"32bit"| v32["רישום בתצוגת ה-32bit"]
    view -->|"64bit"| v64["רישום בתצוגת ה-64bit"]

איור 7: יעד הרישום של LocalServer נקבע לפי תצוגת הרישום שמחולקת לפי bitness.

מה שחשוב במיוחד הוא לא להעתיק בעטיפה 200 שיטות מה-API הישן כמו שהן. אם עושים את זה, פשוט מייבאים את המגבלות הישנות לקוד החדש.

כשעוטפים, שימת לב לדברים האלה עוזרת מאוד:

• להפוך לשיטות בגרגר גס
• לא לתת לקוד המסך לגעת ישירות ב-OCX
• לתעד את הלוג הנדרש בכשל בגבול עצמו
• לקבוע בגבול את האחריות ל-timeout, ניסיון חוזר והמרת חריגות
• לבנות כך שגם התחליף העתידי יוכל להתחלף עם אותו interface

יש גם מקרים שבהם רוצים לשמר רק את כניסת ה-COM בצד ה-‏.NET החדש. במקרה כזה, מבנה של “לעדכן את הפנים תוך שמירה על חוזה ה-COM בלבד” הוא ריאלי. עם זאת, לא בטוח שמספיק “סתם RegAsm” בתחושה של תקופת ה-‏.NET Framework. הטיפול הנוכחי ב-COM host, ב-TLB, ב-bitness וב-Registry-Free COM של ‏.NET כדאי לתכנן מראש — זה נוח יותר בהמשך. פרטים על זה נמצאים ב-איך משתמשים ב-DLL‏ .NET 8 מ-VBA עם טיפוסים — חשיפת COM ו-dscom TLB וב-מהו Reg-Free COM — מנגנון להשתמש ב-COM ללא רישום, כולל שלבים מפורטים.

flowchart TB
    accTitle: אחריות שנקבעת בגבול
    accDescr: תרשים המראה שכשעוטפים הופכים לשיטות בגרגר גס, לא נותנים לקוד המסך לגעת ישירות ב-OCX, קובעים בגבול את אחריות הלוג, ה-timeout וההמרה, ובונים כך שגם התחליף העתידי יוכל להתחלף עם אותו interface.
    b["הגבול בעטיפה"] --> r1["שיטות בגרגר גס"]
    b --> r2["תיעוד לוג בגבול"]
    b --> r3["timeout והמרת חריגות"]
    b --> r4["צוהר אחיד להחלפה עתידית"]
    r1 -.-> ng["לא להעתיק 200 שיטות ישנות"]

איור 8: הערך של העטיפה הוא ריכוז האחריות בגבול; העתקה נאמנה של ה-API הישן לא מייצרת את הערך הזה.

3.4. החלטה להחליף

ההחלפה מתאימה בעיקר במקרים שבהם הבעיה היא ישנוּת השטח בלבד.

כדאי להסתכל מתוך עדיפות להחלפה במקרים כאלה:

• ה-ActiveX משמש רק כרכיב UI
• הספק הוציא ממשיך ל-‏.NET /‏ WPF /‏ WebView2
• תלות בדפדפן או הנחת IE מעכבות
• נתקעים כל פעם ברישום, חתימה, הרשאות מנהל או הגדרות אבטחה
• יש בדיקות או תרחישי עסקיים שאפשר לאמת בהם מימוש חלופי

מנגד, אם זורקים בבת אחת רכיב שנושא לוגיקת בקרת התקן או דוחות רק בגלל שהמראה שלו ישן, זה כמעט תמיד הופך לבוץ.

אם מחליפים, מתחילים מה-UI.

• grid
• לוח שנה
• עץ (tree)
• חלק תצוגת דפדפן
• סיוע קלט פשוט

אלה יחסית קלים להחלפה. מצד שני, יש דברים שנראים כמו UI אבל התוכן שלהם עשיר:

• ActiveX של ספק לבקרת התקן
• פקד שמשולב עם הדפסה או יצירת דוחות
• פקד שכולל קריאה וכתיבה של פורמט קובץ ייחודי
• פקד עם הנחות של callback ב-COM וסביב ת’רדים

אם מפספסים את ההבדל הזה, הערכת המאמץ מתפרקת בבת אחת.

flowchart TB
    accTitle: ההבחנה בהחלטה להחליף
    accDescr: תרשים המראה שאם השימוש הוא רק רכיב UI עם תחליף קל להחליף, אך אם הוא נושא מפרט כמו בקרת התקן, דוחות, פורמט ייחודי או הנחות ת'רד, זריקה מיידית הופכת לבוץ ועדיף לעבור להחלטה לעטוף.
    q{"מה יש מאחורי המראה?"}
    q -->|"רק ישנוּת השטח"| easy["קל להחליף"]
    q -->|"נושא גוש מפרט"| heavy["זריקה מיידית הופכת לבוץ"]
    heavy --> wrap["עברו להחלטה לעטוף"]

איור 9: האם זה מתאים להחלפה נקבע לפי ההבחנה בין “ישנוּת השטח” לבין “עושר התוכן”.

3.5. תלות בדפדפן נשקלת בנפרד

זה בעצם קטגוריה נפרדת לגמרי.

בשונה מ-OCX ב-desktop, ל-ActiveX בדפדפן יש סיבה חלשה למדי להמשיך ולפתח אותו.

הסיבה פשוטה: תשתיות הדפדפנים המודרניים לא הופכות את זה לזירה מרכזית. ‏Microsoft Edge עצמו לא תומך ב-ActiveX. מצד שני, מצב IE משמש כשכבת תאימות שמפעילה מנוע מסדרת IE עבור אתרים שהוגדרו, ומריצה חלק מתכונות IE כולל ActiveX.

כלומר:

• אפשר להאריך חיים כדי שזה יעבוד עכשיו
• אבל כתכנון ארוך טווח, העתיד לא רחב

flowchart TB
    accTitle: המעמד של ActiveX בדפדפן
    accDescr: תרשים המראה ש-Microsoft Edge עצמו לא מריץ ActiveX, ומצב IE מאפשר הארכת חיים כשכבת תאימות עבור אתרים שהוגדרו, אבל העתיד ארוך הטווח דל, ולכן עדיף להסתכל מתוך עדיפות להחלפה.
    bax["ActiveX בדפדפן"] --> edge["לא רץ ב-Edge עצמו"]
    bax --> iem["אפשר להאריך חיים במצב IE"]
    iem --> future["העתיד ארוך הטווח דל"]
    future --> rep["להסתכל מתוך עדיפות להחלפה"]

איור 10: תלות ב-ActiveX בדפדפן — מפרידים בין הארכת חיים לבין תכנון קבוע, ומסתכלים מתוך עדיפות להחלפה.

אותו הדבר קורה גם לפקד WebBrowser שמוטמע באפליקציית Windows. ‏WebBrowser גורר אחריו את “עולם” ה-IE, ולכן אם רק רוצים להציג HTML, טבעי יותר להפוך את WebView2 למועמד הראשון לעבודה חדשה מהיום.

עם זאת, חשוב לזכור ש-WebView2 אינו רכיב חלופי מלא ל-WebBrowser.

• סקריפטים שמניחים DOM של IE
• תלות ב-ActiveX
• הנחות סביב window.external
• התנהגות שמניחה אזורי אבטחה או אינטראנט

אלה לא עוברים כמו שהם. אם מחליפים, צריך לתכנן מחדש לא רק את מנוע הרינדור, אלא גם את שטח החיבור בין הדפדפן ל-native.

flowchart TB
    accTitle: מה לא עובר ל-WebView2
    accDescr: תרשים המראה ש-WebView2 מתאים כמועמד ראשון אם רק רוצים להציג HTML, אבל הוא לא רכיב חלופי מלא, וסקריפטים שמניחים DOM של IE, תלות ב-ActiveX, הנחות window.external והתנהגות אזורי אבטחה לא עוברים כמו שהם.
    wb["מ-WebBrowser ל-WebView2"] --> ok["מועמד ראשון אם רק תצוגת HTML"]
    wb --> ng["מה שלא עובר כמו שהוא"]
    ng --> n1["סקריפטים עם DOM של IE"]
    ng --> n2["תלות ב-ActiveX"]
    ng --> n3["הנחות window.external"]
    ng --> n4["התנהגות אזורי אבטחה"]

איור 11: WebView2 הוא רכיב חלופי למנוע הרינדור, אבל לא יורש את שטח החיבור של עולם ה-IE.

4. נקודות שקל לטעות בהן

4.1. רכיב UI, או רכיב שנושא מפרט

זו הנקודה החשובה ביותר.

grid או לוח שנה ישן — מתקדמים די רחוק רק בבדיקת תאימות המראה והאירועים. מצד שני, ל-ActiveX שנושא בקרת התקן, דוחות או פורמט ייחודי יש גוש מפרט מאחורי המראה.

גם אם זה נראה כמו אותו “פקד על המסך”, בפועל יש טווח כזה:

• רכיב תצוגת רשימה בלבד
• רכיב ששולח פקודות להתקן בפרוטוקול ייחודי
• רכיב שמטפל פנימית גם ב-timeout, חיבור מחדש, שידור חוזר וספיגת חריגות
• רכיב שנושא תאימות הדפסה או פורמט ייצוא

מימוש מחדש מיידי של האחרון הופך כמעט תמיד לפרויקט חפירת מפרט. כאן בטוח יותר לעטוף קודם.

flowchart TB
    accTitle: רכיב UI מול רכיב שנושא מפרט
    accDescr: תרשים המראה שגם אם זה נראה כמו אותו פקד על המסך, רכיב תצוגה בלבד מתקדם רק בבדיקת תאימות, בעוד רכיב שנושא גוש מפרט כמו פקודות להתקן או תאימות דוחות הופך במימוש מחדש מיידי לפרויקט חפירת מפרט, ולכן עדיף לעטוף קודם.
    look["פקד על המסך"] --> ui["רכיב תצוגה בלבד"]
    look --> spec["רכיב שנושא גוש מפרט"]
    ui --> go["בדיקת תאימות מספיקה"]
    spec --> dig["מימוש מחדש מיידי הופך לחפירת מפרט"]
    dig --> wrap["עדיף לעטוף קודם"]

איור 12: ההבחנה החשובה ביותר. גם אם המראה זהה, האם מאחוריו יש גוש מפרט קובע את דרך ההתקדמות.

4.2. ‏32bit /‏ 64bit וגבול התהליכים

לרוב מפספסים את הנקודה הזו, אבל היא ממש מהותית.

OCX‏ ב-in-proc חייב להתאים ב-bitness לתהליך שטוען אותו. כלומר, אי אפשר לטעון OCX‏ 32bit לתוך אפליקציית 64bit ישירות.

האפשרויות הריאליות במקרה הזה הן בעצם השלוש האלה:

• להשאיר בינתיים גם את אפליקציית ה-host כ-32bit
• לכלוא בתהליך 32bit נפרד, ולהתחבר לצד ה-64bit דרך IPC או COM מסוג out-of-proc
• להתחיל להחליף מהמקומות שאפשר להסיר בהם את התלות ב-OCX

כאן, ה-“מכיוון שזה Any CPU זה בטח יסתדר” בדרך כלל לא עובד. גם כשבונים חלון תאימות COM בצד ה-‏.NET החדש, המראה של קוד managed וה-bitness האמיתי של ה-COM host הם בעיות נפרדות. אם מתחילים בזה ברישול, יוצא הדבר המעצבן: ה-build עובר, אבל זה לא עובד אצל הלקוח.

flowchart TB
    accTitle: שלוש האפשרויות ל-OCX 32bit ולמעבר ל-64bit
    accDescr: תרשים המראה שמכיוון ש-OCX 32bit לא נטען ב-in-proc לתוך תהליך 64bit, שלוש האפשרויות הריאליות הן להשאיר את ה-host כ-32bit, לכלוא בתהליך 32bit נפרד ולהתחבר עם IPC או COM out-of-proc, או להחליף מהמקומות שאפשר להסיר בהם את התלות.
    wall["OCX 32bit לא נטען ב-in-proc"] --> o1["השארת ה-host כ-32bit"]
    wall --> o2["כליאה בתהליך 32bit נפרד"]
    wall --> o3["החלפה מהמקומות שאפשר"]
    o2 -.-> ipc["חיבור עם IPC או COM out-of-proc"]

איור 13: את חומת ה-bitness אי אפשר לעבור בכוח רצון; האפשרויות הריאליות מצטמצמות לשלוש אלה.

4.3. רישום, הפצה, הרשאות, רישיונות

טכנית אפשר לקרוא לזה, אבל זה מת בהפצה. זה קורה הרבה מאוד ב-ActiveX /‏ OCX.

המכשולים האופייניים הם בערך אלה:

• ההנחה סביב regsvr32 תלויה באדם
• מיקום ה-DLL התלויים לא מתועד במפורש
• נדרשות הרשאות מנהל, אבל זה לא הוטמע בנוהל התפעול
• רישיון design-time /‏ runtime של פקד הספק מחולק
• עובד במחשב הפיתוח, אבל לא בסביבה נקייה

אלה עוצרים את הפרויקט גם בלי לגעת בשורת קוד אחת.

יש מקרים שבהם מבנה ללא רישום או פריסת side-by-side מקלים, אבל זה לא אבקת קסמים. צריך לוודא התאמה עם ה-container ועם שיטת ההפצה.

בקיצור, מעבר ActiveX /‏ OCX הוא לא רק מימוש, אלא גם תכנון הפצה. אם דוחים את זה, נופלים בגדול בסוף.

flowchart TB
    accTitle: מכשולים שעוצרים בהפצה
    accDescr: תרשים המראה שתלות אנושית ב-regsvr32, מיקום DLL לא מתועד, הרשאות מנהל שלא הוטמעו בנוהל, ורישיון מחולק בין design-time ל-runtime עוצרים את הפרויקט גם בלי לגעת בקוד.
    dist["תכנון ההפצה"] --> d1["regsvr32 תלוי באדם"]
    dist --> d2["DLL תלויים לא מתועדים"]
    dist --> d3["הרשאות מנהל מחוץ לנוהל"]
    dist --> d4["רישיון מחולק לשניים"]
    d1 -.-> stopx["עוצר גם בלי לגעת בקוד"]

איור 14: זה נקרא טכנית, אבל מת בהפצה — מכשול שמתכננים בנפרד מהמימוש עצמו.

4.4. STA / לולאת הודעות / callback

‏ActiveX /‏ OCX הוא לא סתם קריאת DLL. לפעמים יש לו הנחות על מודל התהליכונים של COM ועל לולאת ההודעות.

כדאי במיוחד לשים לב למקרים כאלה:

• יציב רק בהנחת ת’רד ה-UI
• הנחת STA, אבל קוראים לו ברשלנות מצד MTA
• callback חוזר באמצע קריאה סינכרונית
• ההנחה על ת’רד קבלת האירועים לא ברורה

בהתחלה זה מופיע כ”סיפור רפאים”: “לפעמים נתקע”, “לפעמים אירוע לא מגיע”. אבל בפועל, ברוב המקרים זו הפרת הנחה.

לכן, גם כשעוטפים וגם כשמחליפים, כדאי לקבע מראש באיזה ת’רד יוצרים, באיזה ת’רד קוראים, ואיפה מקבלים אירועים.

flowchart TB
    accTitle: קיבוע הנחות הת'רד מראש
    accDescr: תרשים המראה שבלי לקבע מראש באיזה ת'רד יוצרים, באיזה ת'רד קוראים, ואיפה מקבלים אירועים, זה הופך לסיפור רפאים של תקיעה או אירועים חסרים שהם בפועל הפרת הנחה.
    fix["שלוש הנקודות שמקבעים מראש"] --> t1["באיזה ת'רד יוצרים"]
    fix --> t2["באיזה ת'רד קוראים"]
    fix --> t3["איפה מקבלים אירועים"]
    t1 -.-> ghost["אי-בהירות הופכת לסיפור רפאים של הפרת הנחה"]

איור 15: “לפעמים זה נתקע” הוא לרוב הפרת הנחה — קיבוע מראש של הבטחות הת’רד מונע את זה.

4.5. יש בדיקות? אפשר לצפות?

ההחלפה קשה לא רק בגלל שהקוד ישן. אלא בגלל שאין קריטריון לכך ש“זה פעל אותו הדבר”.

עצם קיומם של אלה כבר עושה הבדל גדול:

• smoke test לכל תרחיש הפעלה
• דוגמאות קלט/פלט
• צילומי מסך או דוגמאות דוחות
• תבניות שגיאה והתנהגות צפויה
• לוג בזמן timeout או כשההתקן לא מחובר

כשמעורבים התקן או דוחות, קורה דבר מוזר: ההתנהגות בפועל אמינה יותר מהמפרט הכתוב. בלי אמצעי תצפית כאן, ההחלפה הופכת לחפירה ארכיאולוגית.

flowchart TB
    accTitle: אמצעי תצפית תומכים בהחלפה
    accDescr: תרשים המראה שבלי אמצעי תצפית כמו smoke test, דוגמאות קלט ופלט, דוגמאות דוחות ותבניות שגיאה, אין קריטריון לכך שזה פעל אותו הדבר, וההחלפה הופכת לחפירה ארכיאולוגית.
    q{"יש אמצעי תצפית?"}
    q -->|"יש"| ok["אפשר לומר שזה פעל אותו הדבר"]
    q -->|"אין"| dig["ההחלפה הופכת לחפירה ארכיאולוגית"]
    ok -.-> ex["smoke test ודוגמאות מכל סוג"]

איור 16: קושי ההחלפה נקבע פחות לפי ישנות הקוד, ויותר לפי קיום אמצעי תצפית שיודע לומר “פעל אותו הדבר”.

5. המלצות לפי דפוסים אופייניים

5.1. אפליקציית desktop פנים-ארגונית שיציבה כרגע

ההמלצה: נטייה לשמר.

בתנאים כאלה, לרוב עדיף לא לקלף בכוח:

• נעשה בו שימוש פנים-ארגוני בלבד
• המחשבים ומערכת ההפעלה קבועים במידה מסוימת
• ה-OCX הזה משמש רק בכמה מסכים
• דרישות התיקון קטנות, ואורך החיים צפוי

אבל לא משאירים את זה “עירום” — ריכוז מוקדי הקריאה בלבד ישתלם בהמשך.

כלומר, המדיניות היא כזו:

• כרגע משמרים
• אבל מסדרים רק את הגבול
• כך שכשתידרש החלפה, אפשר יהיה להתחיל משם

המבנה בן שלוש השכבות הזה הכי פשוט.

5.2. רוצים להעביר OCX‏ 32bit לצד 64bit

ההמלצה: לעטוף / לשנות מבנה.

אם ניגשים לזה ישירות, נתקעים. כי אי אפשר לטעון OCX‏ 32bit לתוך תהליך 64bit ב-in-proc.

בפועל, נוח יותר מבנה שכולא בתהליך helper של 32bit או ב-LocalServer, ומתקשר עם אפליקציית ה-64bit דרך API בגרגר גס.

sequenceDiagram
    accTitle: מבנה שבו helper של 32bit מגשר בין אפליקציית 64bit ל-OCX
    accDescr: תרשים רצף המראה שאפליקציית .NET של 64bit פונה ל-helper או LocalServer של 32bit דרך API בגרגר גס, וזה קורא ב-in-proc ל-OCX של 32bit ומחזיר תוצאה מומרת בחזרה.
    participant App as אפליקציית .NET 64bit
    participant Bridge as helper / LocalServer של 32bit
    participant Ocx as OCX של 32bit

    App->>Bridge: פנייה עם API בגרגר גס
    Bridge->>Ocx: קריאה ב-in-proc
    Ocx-->>Bridge: תוצאה / אירוע
    Bridge-->>App: תוצאה מומרת

איור 17: OCX שכלוא ב-helper של 32bit, ואפליקציית ה-64bit משתמשת בו דרך API בגרגר גס.

הנקודה כאן היא לא לתווך את כל השיטות הקטנות כמו שהן. גבול בין-תהליכי מתעייף מהר אם שולחים דרכו הרבה קריאות קטנות.

• להתקרב לגרגר של פעולה אחת = בקשה אחת
• לעצב ערכי החזרה ושגיאות ליחידות בעלות משמעות
• לתעד לוג בגבול

בצורה הזו, גם קל יותר בהמשך כשבאמת מחליפים את הפנים.

5.3. מסך שמניח IE /‏ WebBrowser

ההמלצה: עדיפות להחלפה.

זה תחום שבו “עובד עכשיו” ו”קל לתחזק גם בהמשך” לא בקלות מתלכדים. מצב IE עוזר מאוד לתאימות, אבל ההנחה עדיין נשארת מסדרת IE.

לכן, ברור יותר לחלק את החשיבה כך:

• להאריך חיים במצב IE כדי לא לעצור פעילות פנים-ארגונית
• אבל לא לבלבל בין הארכת חיים לתכנון קבוע
• לבחור יעד החלפה מבין WebView2, Web טהור, או היברידי של UI native + Web

נכתוב גם את הטיפול הקונקרטי בצד הארכת החיים. מצב IE הוא לא משהו ש”פועל מעצמו כשמתקינים Edge” — הוא נפתח עם מנוע מסדרת IE רק אחרי שמציינים את האתר היעד במדיניות (policy). שלושה ערוצי הגדרה:

התנאים המקדימים: עדכונים אחרונים ל-Windows ול-Edge, תבנית הניהול (template) של Microsoft Edge מותקנת, ותכונת Windows של Internet Explorer 11 מופעלת. אם אחד מאלה חסר, מצב IE נכשל.

בנוסף, במצב IE פועלים גם פקדי ActiveX וגם Browser Helper Object. כלומר, הארכת החיים באמת עובדת. בדיוק בגלל זה, אם ממשיכים להשתמש בזה בלי לקבוע תנאי סיום, אי אפשר להיחלץ. איך לקלף מוסבר ב-מדריך היציאה ממערכת שתלויה במצב IE.

flowchart TB
    accTitle: אופן החשיבה על הארכת חיים במצב IE
    accDescr: תרשים המראה שרק אחרי שמציינים את האתר היעד במדיניות, המצב נפתח כמצב IE, ואפשר להאריך חיים כולל ActiveX, אבל אם לא קובעים תנאי סיום ומשתמשים בזה כך, אי אפשר להיחלץ.
    policy["ציון אתר יעד במדיניות"] --> iem["נפתח במצב IE"]
    iem --> alive["הארכת חיים כולל ActiveX"]
    alive --> cond["שימוש עם תנאי סיום"]
    cond -.-> exitw["בלי תנאי סיום אי אפשר להיחלץ"]

איור 18: הארכת החיים של מצב IE “באמת עובדת” — בדיוק בגלל זה כדאי להשתמש בה יחד עם תנאי סיום.

בפרט אם משתמשים בפקד WebBrowser רק כמציג HTML פשוט, עדיפות ההחלפה גבוהה.

מצד שני, אם ה-ActiveX בתוך הדפדפן נושא גם תפקידים כמו קובץ מקומי, התקן, חתימה או תוסף ייחודי, זה כבר לא החלפת מנוע רינדור, אלא תכנון מחדש של החיבור ל-native. כאן הסיפור מתחיל להיות כבד יותר.

5.4. ActiveX עם בקרת התקן או מפרט ייחודי

ההמלצה: קודם לעטוף.

הסוג הזה, התוכן שלו עשיר יותר מהמראה. גם אם תיעוד ה-SDK דל, כתוצאה משנים של הפעלה בשטח, עשויים להצטבר בו התנהגויות שקטות כאלה:

• אופן ההמתנה בכשל חיבור
• ניסיון חוזר אחרי timeout
• סדר האירועים
• טיפול עוקף שסופג הרגלים של המכשיר בפועל
• פרשנות של חריגות וקודי שגיאה

אם בונים מחדש רכיב מהסוג הזה רק בגלל “זה ממילא ישן”, יש סיכוי גבוה שבדיקות השטח יישרפו.

לכן, בטוח יותר להתחיל מכאן:

1. לכלוא את הרכיב הקיים בתוך הגבול
2. להוסיף לוג כדי לראות מה קורה
3. לאסוף תרחישי בדיקה ותבניות ממכשיר אמיתי
4. ורק אז לחתוך את הטווח הניתן להחלפה

זה לא מרשים, אבל בעבודה בפועל זה הכי יעיל.

flowchart TB
    accTitle: הסדר להתקדמות עם ActiveX שנושא מפרט
    accDescr: תרשים המראה שהסדר הוא לכלוא את הרכיב הקיים בתוך הגבול, להוסיף לוג לחשיפה, לאסוף תרחישי בדיקה ותבניות ממכשיר אמיתי, ורק אז לחתוך את הטווח הניתן להחלפה.
    s1["כליאה בתוך הגבול"] --> s2["הוספת לוג לחשיפה"]
    s2 --> s3["איסוף תרחישים ותבניות אמיתיות"]
    s3 --> s4["חיתוך הטווח הניתן להחלפה"]

איור 19: רכיב שנושא בקרת התקן או מפרט ייחודי — בסדר הזה בדיקות השטח פחות נשרפות.

6. אנטי-דפוסים נפוצים

מבין אלה, שלושה נראים במיוחד בעבודה בפועל:

1. ממהרים לכתיבה מחדש מלאה
2. מזלזלים בחומת ה-bitness
3. מפזרים API על פני כל האפליקציה

רק הימנעות משלושת אלה כבר מורידה משמעותית את שיעור התקלות.

flowchart TB
    accTitle: שלושת האנטי-דפוסים הנפוצים ביותר
    accDescr: תרשים המראה שהימנעות משלושה דברים — מיהור לכתיבה מחדש מלאה, זלזול בחומת ה-bitness, ופיזור API על פני כל האפליקציה — מורידה משמעותית את שיעור התקלות.
    a1["מיהור לכתיבה מחדש מלאה"] --> avoid["הימנעות משלושת אלה"]
    a2["זלזול בחומת ה-bitness"] --> avoid
    a3["פיזור API על כל האפליקציה"] --> avoid
    avoid --> down["שיעור תקלות נמוך משמעותית"]

איור 20: מבין האנטי-דפוסים, שלושת אלה הכי נפוצים, וההימנעות מהם משפיעה הכי הרבה.

7. רשימת בדיקה להתחלת מעבר

בפרויקט ActiveX /‏ OCX, מוצלח יותר לעשות קודם מיפוי מלא ורק אז להיכנס למימוש. הסדר הוא בערך כך:

1. למפות את ה-OCX /‏ DLL שנמצאים בשימוש
   • שם קובץ, גרסה, ProgID,‏ CLSID, ספק, קיום רישיון
2. למפות איפה נעשה בהם שימוש
   • מסך, תכונה, דוח, התקן, batch, אינטגרציית Office וכדומה
3. לבדוק את תנאי ה-bitness וה-host
   • 32bit /‏ 64bit,‏ in-proc /‏ out-of-proc, הנחת STA, תלות בדפדפן
4. לבדוק את תנאי ההפצה
   • שיטת רישום, DLL תלויים, הרשאות מנהל, התקנה שקטה, שחזור בסביבה נקייה
5. להכין smoke test
   • לא רק מסלול רגיל, גם כשל, חוסר חיבור ו-timeout
6. ליצור גבול
   • adapter,‏ service,‏ facade, גישור לתהליך נפרד וכדומה
7. לנסות ביחידה קטנה — מסך אחד, תכונה אחת, התקן אחד
8. מהגבול שהצליח, להרחיב בהדרגה את לשמר / לעטוף / להחליף

אם מדלגים על השלבים האלה, בהמשך קשה אפילו להסביר “מה בכלל היה קשה”.

8. חלוקה גסה בין המצבים

כשמתלבטים, אם קודם מבחינים אם זה רכיב UI או ממשק גבול שנושא מפרט, קשה בהרבה לטעות.

9. סיכום

איך מתייחסים ל-ActiveX /‏ OCX זה לא נושא שמחליטים לפי “זה legacy אז שונאים את זה”.

יש ארבע נקודות שצריך להסתכל עליהן קודם:

1. האם הרכיב סתם UI, או ממשק גבול שנושא מפרט
2. האם צריך להשתמש בו באותו תהליך
3. האם 32bit /‏ 64bit, רישום, תלות בדפדפן או רישיון חוסמים
4. האם אפשר לצפות בהתנהגות לפני ההחלפה

אם ארבעת אלה ברורים, בערך אפשר לסדר כך:

• יציב וצפוי — לשמר
• רוצים לחדש רק את הסביבה — לעטוף
• רכיב UI או תלות בדפדפן — להחליף
• רכיב שנושא גוש מפרט — קודם לעטוף ואז להחליף בהדרגה

טכנולוגיית legacy היא לא נושא ללעג, אלא חפץ ממשי מלא היסטוריה וחוזים. עם זאת, כדי להתמודד עם החפץ הזה נדרש תכנון גבול.

כשלומדים לחשוב על “לשמר, לעטוף, להחליף” יחד, פרויקט ActiveX /‏ OCX הופך פתאום לבעיה שאפשר להתמודד איתה.

flowchart TB
    accTitle: הסידור המסכם
    accDescr: תרשים המראה שאם יציב וצפוי משמרים, אם רוצים לחדש רק את הסביבה עוטפים, אם רכיב UI או תלות בדפדפן מחליפים, ואם זה גוש מפרט קודם עוטפים ואז מחליפים בהדרגה.
    q["איך מתייחסים ל-ActiveX / OCX"] --> k["יציב וצפוי — לשמר"]
    q --> w["חידוש הסביבה — לעטוף"]
    q --> r["UI או תלות בדפדפן — להחליף"]
    q --> p["גוש מפרט — לעטוף ואז להחליף בהדרגה"]

איור 21: אם ארבע נקודות ההסתכלות ברורות, לשמר / לעטוף / להחליף מסתדרים בצורה הזו.

10. סוג ההתייעצות שמתאים לזה

בנושא הזה, יש ערך גם רק בסידור המדיניות לפני שנכנסים ישר לפיתוח.

לדוגמה, ההתייעצויות האלה מתאימות מאוד:

• רוצים למפות אילו OCX-ים באמת צריך להחליף
• רוצים לסדר קודם רק את נקודות התקיעה של 32bit /‏ 64bit
• רוצים לעבור ל-‏.NET, אבל לשמר רק את כניסת ה-COM
• רוצים להשוות בין הארכת חיים לנסיגה עבור ActiveX שהספק שלו סיים תמיכה
• רוצים לראות מאיפה אפשר להתחיל לקלף את התלות ב-IE /‏ WebBrowser
• רוצים להפריד קודם בבטחה מסך אחד, תכונה אחת

בפרויקט ActiveX /‏ OCX, לרוב איך חותכים את הגבול קובע יותר מהמימוש עצמו. כשלב מקדים לשיפוץ מלא, יש ערך רב כבר רק בסידור מצב קיים, השוואת מבנים ותכנון סדר המעבר.

11. מקורות

• Microsoft Learn: AxHost Class (System.Windows.Forms)
  • https://learn.microsoft.com/ja-jp/dotnet/api/system.windows.forms.axhost
• Microsoft Learn: Aximp.exe (Windows フォーム ActiveX コントロール インポーター)
  • https://learn.microsoft.com/ja-jp/dotnet/framework/tools/aximp-exe-windows-forms-activex-control-importer
• Microsoft Learn: How to: Add ActiveX Controls to Windows Forms
  • https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/how-to-add-activex-controls-to-windows-forms
• Microsoft Learn: Expose .NET Core components to COM
  • https://learn.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com
• Microsoft Learn: Registration-Free COM Interop
  • https://learn.microsoft.com/en-us/dotnet/framework/interop/registration-free-com-interop
• Microsoft Learn: Microsoft Edge に関してよく寄せられる質問
  • https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-frequently-asked-questions
• Microsoft Learn: What is Internet Explorer (IE) mode?
  • https://learn.microsoft.com/en-us/deployedge/edge-ie-mode
• Microsoft Learn: WebBrowser Class (System.Windows.Forms)
  • https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.webbrowser
• Microsoft Learn: Introduction to Microsoft Edge WebView2
  • https://learn.microsoft.com/en-us/microsoft-edge/webview2/
• KomuraSoft Blog: הידע הבסיסי למניעת תקיעה עם STA/MTA של COM
  • /he/blog/sta-mta-com-relationship/
• KomuraSoft Blog: כשמשתמשים ב-DLL native של ‏C++ מתוך ‏C#, למה עדיף לבנות עוטף עם ‏C++/CLI
  • /he/blog/cpp-cli-wrapper-for-native-dlls/
• KomuraSoft Blog: מקרה שבו COM שימושי — כשרוצים לקרוא ל-DLL‏ 64bit מאפליקציית 32bit
  • /he/blog/com-case-study-32bit-to-64bit/
• KomuraSoft Blog: מה זה COM /‏ ActiveX /‏ OCX — הסבר מרוכז על ההבדלים והקשרים
  • /he/blog/what-is-com-activex-ocx/
• KomuraSoft Blog: איך משתמשים ב-DLL‏ .NET 8 מ-VBA עם טיפוסים — חשיפת COM ו-dscom TLB
  • /he/blog/dotnet8-dll-typed-vba-com-dscom-tlb/
• KomuraSoft Blog: מהו Reg-Free COM — מנגנון להשתמש ב-COM ללא רישום
  • /he/blog/what-is-reg-free-com/
• KomuraSoft Blog: המלכודות שברישום וב-bitness בפיתוח COM/OCX/ActiveX
  • /en/blog/2026/04/15/001-com-ocx-activex-pitfalls-visual-studio-bitness-admin-rights/
• KomuraSoft Blog: מדריך היציאה ממערכת שתלויה במצב IE
  • /en/blog/2026/04/25/003-ie-mode-internal-web-system-life-extension-and-exit/
• KomuraSoft Blog: אחרי מצב IE, האם WebView2 מספיק? — המגבלה שבה ActiveX לא פועל, ותכנון מעבר ריאלי
  • /en/blog/webview2-embed-web-ui-in-windows-apps/

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

כדאי להחליף ActiveX /‏ OCX?

ההחלטה לא נשענת על "האם זה ישן", אלא על מה שהרכיב הזה בעצם אחראי עליו. אם זה רק רכיב UI ויש לו תחליף — מחליפים; אם הוא כולל בקרת התקן, דוחות או פורמט קובץ ייחודי — קודם עוטפים ומסדרים את הגבול; ואם הוא יציב ותחום השינויים בו קטן — גם החלטה לשמר אותו ריאלית. גם "סתם לכתוב הכול מחדש" וגם "להקפיא לנצח כי זה מפחיד" הן בחירות עם שיעור תקלות גבוה.

אפשר להשתמש ב-OCX‏ 32bit מתוך אפליקציית 64bit?

לא ב-in-proc. ה-OCX חייב להתאים ל-bitness של התהליך שטוען אותו — זו מגבלה עקרונית. שלוש האפשרויות הריאליות הן: להשאיר בינתיים גם את אפליקציית ה-host כ-32bit; לכלוא אותו בתהליך 32bit נפרד (helper EXE או COM LocalServer) ולהתחבר אל צד ה-64bit דרך IPC או COM מסוג out-of-proc; או להתחיל להחליף מהמקומות שבהם אפשר להסיר את התלות ב-OCX.

מה עושים עם תלות ב-ActiveX בדפדפן?

עדיף להסתכל על זה מתוך עדיפות להחלפה. Microsoft Edge עצמו לא תומך ב-ActiveX, ומצב IE (IE mode) ממוקם כאמצעי הארכת חיים בלבד. גם פקד WebBrowser גורר אותו "עולם" של IE, ולכן אם רק רוצים להציג HTML, ‏WebView2 הוא המועמד הראשון. עם זאת, WebView2 אינו רכיב חלופי מלא: סקריפטים שמניחים DOM של IE וההנחות סביב window.external לא עוברים כמו שהם.

מה זה אומר בפועל "לעטוף" ActiveX /‏ OCX?

לכלוא את ה-ActiveX /‏ OCX בתוך גבול צר, ולהראות אותו לסביבה כ-API חדש או כרכיב מסך. יש כמה תבניות: host ב-WinForms עם AxHost, גישור לתהליך נפרד עם helper EXE של 32bit או LocalServer, וחלון תאימות COM בצד ה-‏.NET. כשעוטפים, לא מעתיקים את ה-API הישן בהמוניו — הופכים אותו לשיטות בגרגר גס, קובעים בגבול את האחריות ללוג, timeout והמרת חריגות, ובונים כך שאפשר יהיה להחליף בעתיד גם את התחליף עם אותו interface.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.