ما هو VBA - القيود، والآفاق، ومتى يُستبدَل، وأنماط الترحيل الواقعيّة

في استشارات VBA تختلط أحاديث من هذا النوع بسرعة.

• ما VBA أصلاً
• يُقال إن الماكرو خطر، فهل ينبغي التوقّف عن استخدامه
• هل سيتعذّر استخدامه قريباً
• هل يكفي نقل الكلّ إلى Office Scripts أو Power Automate
• هل نُبقي أصول .xlsm أو Access القائمة أم نتخلّى عنها
• هل يجوز تشغيل Excel في دفعة ليليّة أو على خادم

هذه المواضيع لا تُحَلّ بإجابة واحدة نظيفة. ما ينبغي النظر إليه أوّلاً ليس الجدة أو القِدَم، بل أين يُشغَّل، ومن يستخدمه، وهل Excel / Access نفسه هو الـ UI، وهل التنفيذ غير مراقب.

flowchart TB
    accTitle: المحاور التي تُرى أوّلاً عند الحكم على VBA
    accDescr: مخطّط يبيّن أن الحكم على مواصلة VBA أو استبداله ينبغي أن ينظر أوّلاً إلى أين يُشغَّل ومن يستخدمه وهل Excel أو Access نفسه هو الـ UI وهل التنفيذ غير مراقب، لا إلى الجدة أو القِدَم.
    a0["الجدة أو القِدَم"] -.-> a1["ليس المحور الذي يُرى أوّلاً"]
    b0["المحاور التي ينبغي رؤيتها أوّلاً"] --> b1["أين يُشغَّل"]
    b0 --> b2["من يستخدمه"]
    b1 --> b3["هل Excel / Access نفسه هو الـ UI"]
    b2 --> b4["هل التنفيذ غير مراقب"]

الشكل 1: محاور الحكم على VBA ليست الجدة والقِدَم، بل مكان التشغيل والمستخدم والـ UI والتنفيذ غير المراقب.

ترتّب هذه المقالة الموضوع بهذا التسلسل: ما VBA، وأين تقع القيود، وهل سيتعذّر استخدامه، ومتى ينبغي الاستبدال، وكيف يبدو الترحيل المرحلي الواقعي. المحتوى يقوم على المعلومات الرسميّة من Microsoft التي يمكن التحقّق منها حتى مارس 2026.¹²³⁴⁵

1. الخلاصة أوّلاً

نضع الخلاصة أوّلاً.

• VBA لغة موجَّهة بالأحداث لتوسيع تطبيقات Office لسطح المكتب. التقنية تفترض العمل داخل Excel وWord وPowerPoint وAccess وما شابه.¹
• حتى مارس 2026 على الأقل، لا يظهر في المعلومات الرسميّة من Microsoft إعلان واضح بأن «VBA نفسه سيُنهى قريباً». ما يحدث الآن أقرب إلى اتّضاح أماكن الاستخدام وشروطه منه إلى «إلغاء مفاجئ شامل».¹²³⁴
• تحديداً، لا يمكن إنشاء VBA أو تشغيله أو تحريره في Excel for the web. كذلك تُحظَر ماكروهات الملفّات ذات الأصل من الإنترنت افتراضيّاً.²³
• لذلك النقطة الآن ليست «هل نتخلّى عن VBA كلّه»، بل أيّ مجال نُبقيه في VBA وأيّ مجال نخرجه.
• خصوصاً، المعالجة التي تحتاج تنفيذاً غير مراقب، أو تشغيلاً على خادم، أو تشغيلاً متعدّد المستخدمين، أو دعماً للمتصفّح، أو توزيعاً مركزيّاً، أو تدقيقاً صارماً أطبيعيّ ألّا تُحمَل بـ VBA وحده. Microsoft أيضاً لا توصي بأتمتة Office من جانب الخادم ولا تدعمها.⁶
• وجهة الاستبدال ليست واحدة. التقسيم الواقعي: إن بقي Excel فأخرج المعالجة إلى DLL من .NET أو عمليّة أخرى، ولمسار العمل على Microsoft 365 استخدم Office Scripts + Power Automate، وللتوسيع متعدّد المنصّات Office Add-ins، وإن لم يعد Excel هو الـ UI أصلاً فأخرج إلى تطبيق Windows أو ويب.⁴⁵⁶

باختصار، الأعمليّ رؤية VBA لا كـ «تقنية تموت فوراً» بل كـ «تقنية صار موضعها الأنسب واضحاً».

flowchart TB
    accTitle: كيف نرى التغيّر الجاري
    accDescr: مخطّط يبيّن أن ما يحدث الآن ليس إلغاءً مفاجئاً شاملاً بل اتّضاح أماكن الاستخدام وشروطه، وأن النقطة ليست التخلّي عن VBA كلّه بل أيّ مجال يُبقى فيه وأيّ مجال يُخرَج.
    c1["إلغاء مفاجئ شامل"] -.-> c2["لا يظهر في المعلومات الرسميّة"]
    d1["اتّضاح أماكن الاستخدام وشروطه"] --> d2["تتغيّر النقطة"]
    d2 --> d3["أيّ مجال يُبقى في VBA"]
    d2 --> d4["أيّ مجال يُخرَج"]

الشكل 2: النقطة ليست «هل نتخلّى عن الكلّ» بل تقسيم المجال الذي يبقى والمجال الذي يُخرَج.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 23، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. ما VBA

VBA اختصار Visual Basic for Applications، وهو نوع من Visual Basic المرفق مع Microsoft Office. توضّحه الوثائق الرسميّة من Microsoft أيضاً بأنّه لغة برمجة موجَّهة بالأحداث لتوسيع تطبيقات Office.¹⁷

المهم هنا أن رؤية VBA كـ لغة توسيع تُدخَل داخل تطبيق Office أقرب إلى الواقع من رؤيته كـ أساس تطوير تطبيقات عام.

flowchart TB
    accTitle: الرؤية الصحيحة لـ VBA
    accDescr: مخطّط يبيّن أن رؤية VBA كلغة توسيع موجَّهة بالأحداث تُدخَل داخل تطبيق Office أقرب إلى الواقع من رؤيته كأساس تطوير تطبيقات عام.
    v1["VBA"] --> j1{"كيف نراه"}
    j1 -.->|"بعيد عن الواقع"| a1["أساس تطوير تطبيقات عام"]
    j1 -->|"قريب من الواقع"| a2["لغة توسيع تُدخَل داخل تطبيق Office"]
    a2 --> a3["لغة موجَّهة بالأحداث تعمل داخل Office"]

الشكل 3: VBA ليس أساس تطوير عامّاً، بل لغة توسيع تُدخَل داخل Office.

في Excel مثلاً يعمل قريباً من أهداف من هذا النوع.

• Workbook
• Worksheet
• Range
• الأزرار والنماذج
• أحداث فتح المصنّف وحفظه وتغيير الخلية

أي أن قوّة VBA هي القرب الشديد من شاشة Excel أو Access ومن التقرير ومن بنية المصنّف. المستخدم يفتح Office على سطح المكتب، يضغط زراً، يعالج بيانات ملفّ محلّي أو مجلّد مشترك، ويخرج التقرير كما هو. لهذا النوع من «الأتمتة التي تكتمل في يد المستخدم» ما زالت له قوّة.¹

الشيفرة الفعليّة بهذا القصر مثلاً. أصغر شكل يُربَط بزرّ على الورقة.

' يُوضَع في وحدة Excel القياسية. يُفتَرَض استدعاؤه من زرّ على الورقة
Option Explicit

Public Sub ClearMeisai()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Worksheets("التفاصيل")

    If MsgBox("سيتم حذف الصف 2 فما بعد في ورقة التفاصيل. هل توافق؟", _
              vbOKCancel + vbQuestion, "تأكيد") <> vbOK Then
        Exit Sub
    End If

    ws.Rows("2:" & ws.Rows.Count).ClearContents
End Sub

ضع زراً من شكل أو عنصر تحكّم نموذج على الورقة، واختر هذا ClearMeisai من «تعيين ماكرو» بزرّ أيمن، فتعمل هذه المعالجة عند كل ضغط. ما ينبغي النظر إليه هنا هو ظهور كائنات Excel مثل ThisWorkbook وWorksheets وRows مباشرة بلا تحويل ولا استدعاء API. «لغة تعمل داخل Office» تعني تحديداً هذا القرب. بالمقابل، وجهة استبدال يضيع فيها هذا القرب لا تُكتَب بنفس عدد الخطوات.

بالمقابل، نطاق VBA الأصلي منذ البداية ليس الخادم، أو المتصفّح، أو الجوّال، أو نظام ويب متعدّد المستأجرين.

flowchart TB
    accTitle: نطاق VBA
    accDescr: مخطّط يبيّن أن VBA قريب من شاشة Excel أو Access ومن التقرير ومن بنية المصنّف، وما زال قويّاً في الأتمتة التي تكتمل في يد المستخدم، بينما الخادم والمتصفّح والجوّال ونظام الويب متعدّد المستأجرين ليست نطاقه الأصلي منذ البداية.
    s1["قريب مباشرة من كائنات Excel"] --> s2["أتمتة تكتمل في يد المستخدم"]
    s2 --> s3["مجال ما زال قويّاً"]
    t1["خادم / متصفّح / جوّال / نظام ويب"] -.-> t2["ليس النطاق الأصلي منذ البداية"]

الشكل 4: القرب من Office هو القوّة، والموضع الذي لا يحتاج ذلك القرب خارج النطاق منذ البداية.

3. لماذا ما زال يُستخدم

سبب بقاء VBA في الميدان ليس «القِدَم والجمود» وحده.

أوّلاً، يسهل أن يدخل Excel وAccess إجراء العمل نفسه لا البيانات وحدها.

• مظهر التقرير
• إعداد الطباعة
• فحص الإدخال
• ترتيب المعالجة الشهريّة
• قواعد الاستثناء حسب القسم
• خطوات التشغيل التي اعتادها الميدان سنوات

عند النقل إلى نظام آخر لا يكفي «ترحيل الشيفرة». المظهر والتشغيل والاستثناء والتشغيل اليومي مدمجة، فأصل VBA يحمل مواصفات أكثر ممّا يبدو.

flowchart TB
    accTitle: ما يحمله أصل VBA
    accDescr: مخطّط يبيّن أن Excel وAccess يسهل أن يدخلهما إجراء العمل نفسه من مظهر التقرير وإعداد الطباعة وفحص الإدخال وترتيب المعالجة وقواعد الاستثناء وخطوات التشغيل، وأن المظهر والتشغيل والاستثناء والتشغيل اليومي مدمجة فلا يكفي ترحيل الشيفرة.
    e1["أصل Excel / Access"] --> e2["يدخل فيه إجراء العمل نفسه"]
    e2 --> f1["مظهر التقرير وإعداد الطباعة"]
    e2 --> f2["فحص الإدخال وترتيب المعالجة"]
    e2 --> f3["قواعد الاستثناء وخطوات التشغيل"]
    f2 --> g1["ترحيل الشيفرة وحده لا يكفي"]

الشكل 5: أصل VBA لا يحمل الشيفرة فقط، بل إجراء العمل والتشغيل اليومي بالكامل.

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

في الممارسة التفكير الطبيعي كالتالي.

• إن بقي Excel هو الـ UI، فهناك قيمة لإبقاء جزء من VBA
• إن كان Excel إدخالاً وإخراجاً فقط، يسهل إخراج المنطق الداخلي
• إن لم يعد Excel هو الـ UI الأصلي، يصير مرشّحاً لإعادة البناء

flowchart TB
    accTitle: التفكير بموضع Excel كـ UI
    accDescr: مخطّط يبيّن التفكير العملي: إن بقي Excel هو الـ UI فهناك قيمة لإبقاء جزء من VBA، وإن كان إدخالاً وإخراجاً فقط يسهل إخراج المنطق، وإن لم يعد هو الـ UI الأصلي يصير مرشّحاً لإعادة البناء.
    q1{"ما موضع Excel"}
    q1 -->|"يبقى هو الـ UI"| r1["قيمة لإبقاء جزء من VBA"]
    q1 -->|"إدخال وإخراج فقط"| r2["يسهل إخراج المنطق"]
    q1 -->|"لم يعد هو الـ UI الأصلي"| r3["مرشّح لإعادة البناء"]

الشكل 6: كون Excel هو الـ UI أو لا يفرّق اتجاه الإبقاء والإخراج وإعادة البناء.

4. القيود الرئيسة لـ VBA

4.1 الافتراض هو سطح المكتب

أكبر قيد هو هذا. VBA تقنية تعمل أساساً داخل Office لسطح المكتب.

المعلومات الرسميّة من Microsoft أيضاً تقول إن Excel for the web لا يمكن فيه إنشاء VBA أو تشغيله أو تحريره، وإن فتح مصنّف مع ماكرو وتحريره ممكن لكن تشغيل VBA غير ممكن.²⁸

عند هذه النقطة تسوء الملاءمة مع متطلّبات من هذا النوع.

• الاكتمال في المتصفّح
• استخدام التوسيع نفسه عبر Mac / iPad / الويب
• توزيع مركزي من المسؤول
• عدم الاعتماد على تطبيق Excel لسطح المكتب المحلّي

Microsoft نفسها ترشد في وثائق VBA إلى النظر إلى Office Add-ins إن أردت توسيعاً متعدّد المنصّات.⁹⁵

flowchart TB
    accTitle: قيد الافتراض سطح المكتب
    accDescr: مخطّط يبيّن أن VBA تقنية تعمل داخل Office لسطح المكتب، ولا يمكن الإنشاء أو التشغيل أو التحرير في Excel for the web، فتسوء الملاءمة مع الاكتمال في المتصفّح أو المتطلّبات عبر المنصّات، ويُرشد إلى Office Add-ins للتوسيع متعدّد المنصّات.
    h1["VBA"] --> h2["يعمل داخل Office لسطح المكتب"]
    h2 --> h3["لا إنشاء ولا تشغيل ولا تحرير في Excel for the web"]
    h3 --> h4["ملاءمة سيّئة مع الاكتمال في المتصفّح أو التوزيع المركزي"]
    h4 -.-> h5["للتعدّد المنصّات انظر Office Add-ins"]

الشكل 7: أكبر قيد هو افتراض سطح المكتب.

4.2 احتكاك كبير في الأمن والتوزيع

جزء كبير من سوء الفهم بأن VBA «صار غير قابل للاستخدام» هو في الواقع تعزيز الأمن.

جعلت Microsoft ماكرو VBA في الملفّات ذات الأصل من الإنترنت محظوراً افتراضيّاً. فتح .xlsm مرفق بالبريد أو مُنزَّل لم يعد يعمل بسلاسة كما في الماضي.³

هذا الاتجاه صحيح أمنيّاً. لكن من جهة التشغيل يزداد الاحتكاك:

• التوزيع كمرفق لا يعمل
• القالب المُنزَّل من موقع خارجي لا يعمل
• التعامل عبر OneDrive / SharePoint / الشبكة يصعب فهمه
• إرشاد «فعِّل من فضلك» يصير نقطة ضعف تشغيليّة

flowchart TB
    accTitle: الاحتكاك الذي يولّده حظر الماكرو الافتراضي
    accDescr: مخطّط يبيّن أن ماكرو VBA في الملفّات ذات الأصل من الإنترنت محظور افتراضيّاً، فلا يعمل المرفق أو الملفّ المُنزَّل كما في الماضي، فيزداد احتكاك التوزيع والتشغيل.
    m1["ملفّ ذو أصل من الإنترنت"] --> m2["ماكرو VBA محظور افتراضيّاً"]
    m2 --> m3["المرفق أو التنزيل لا يعمل بسلاسة"]
    m3 --> m4["يزداد احتكاك التوزيع والتشغيل"]
    m2 -.-> m5["الاتجاه صحيح أمنيّاً"]

الشكل 8: جزء كبير من سوء الفهم بأنّه «صار غير قابل للاستخدام» هو حظر الماكرو الافتراضي.

لكن الأمر ليس «لا يعمل فانتهى». Microsoft ترتّب في الوثيقة نفسها أيضاً وسائل لتشغيل ماكرو الملفّات الموثوقة. الأربعة الشائعة في التشغيل كالتالي.³

في الوقت نفسه النقاط التالية واضحة أيضاً.³

• الموقع الموثوق والمواقع الموثوق بها تعني الثقة بكلّ ما وُضع هناك. يلزم الاقتصار على موضع يمكن فيه إدارة «من يستطيع الكتابة»
• الناشر الموثوق إعداد لـ Windows ككلّ، وليس حديث Office وحده
• الوظيفة الإضافيّة لـ Excel (.xla / .xlam) لا تعمل حتى مع التوقيع والثقة بالناشر إن وُجد Mark of the Web. هنا إمّا إزالة Mark of the Web أو الوضع في موقع موثوق
• فتح مشاركة شبكيّة بعنوان IP وحده قد لا يقع في المواقع الموثوق بها ولا في الإنترانت المحلّيّة، فيُحظَر

بعبارة أخرى، إن قرّرت إبقاء VBA يلزم، بمعزل عن حديث الشيفرة، تقرير «أين تضع وكيف تثق» كتصميم توزيع. استمرار توزيع .xlsm كمرفق بريد دون تقرير ذلك هو الشكل الأكبر احتكاكاً.

أي أن مشكلة VBA لا تقتصر على «وظائف اللغة»، بل تحدث أيضاً في تصميم التوزيع والثقة.

flowchart TB
    accTitle: إن أبقيت VBA فاحسم تصميم التوزيع أيضاً
    accDescr: مخطّط يبيّن أن قرار إبقاء VBA يلزم معه، بمعزل عن حديث الشيفرة، تقرير أين تضع وكيف تثق كتصميم توزيع، وأن استمرار توزيع .xlsm كمرفق دون تقرير ذلك هو الشكل الأكبر احتكاكاً.
    p1["قرار إبقاء VBA"] --> p2["حديث الشيفرة"]
    p1 --> p3["حديث تصميم التوزيع"]
    p3 --> p4["أين تضع"]
    p3 --> p5["كيف تثق"]
    p4 -.-> p6["التوزيع كمرفق .xlsm دون تقرير = أكبر احتكاك"]

الشكل 9: إن قرّرت الإبقاء فصمّم، بمعزل عن الشيفرة، موضع الوضع وطريقة الثقة.

4.3 حاجز 32 بت / 64 بت

Office له إصدار 32 بت وإصدار 64 بت، والافتراضي في Office 2019 وMicrosoft 365 هو 64 بت.⁷

لذلك شيفرة VBA القديمة، خصوصاً ما يستدعي Windows API بـ Declare، قد لا تعمل كما هي في بيئة 64 بت. Microsoft أيضاً ترشد إلى امتصاص فرق 32 بت / 64 بت بـ PtrSafe وLongPtr وLongLong وما شابه.⁷

ما يصعب هنا أن المشكلة لا تقتصر على الشيفرة، بل يسهل أن تصير هذه الاعتمادات مشكلة معها.

• COM / ActiveX / OCX قديم
• DLL خارجي بافتراض 32 بت
• مكوّن يفترض تسجيل السجلّ
• انحراف إعدادات الإشارة في Office

أي أن ترحيل VBA في كثير من الأحيان يصير ترتيب bitness في Office والاعتماد الخارجي أكثر منه إعادة كتابة اللغة.

flowchart TB
    accTitle: حاجز 32 بت / 64 بت
    accDescr: مخطّط يبيّن أن الافتراضي في Office 2019 وMicrosoft 365 هو 64 بت، فشيفرة Declare القديمة لاستدعاء Windows API قد تحتاج معالجة بـ PtrSafe وLongPtr، وأن COM وActiveX وDLL بافتراض 32 بت وانحراف الإشارة تصير مشكلة معها، فيصير الترحيل ترتيب اعتماد خارجي أكثر من إعادة كتابة اللغة.
    b1["Office 2019 / M365 الافتراضي 64 بت"] --> b2["استدعاء Declare القديم قد لا يعمل كما هو"]
    b2 --> b3["امتصاص الفرق بـ PtrSafe وLongPtr"]
    b2 -.-> b4["COM / ActiveX / OCX وDLL بافتراض 32 بت تصير مشكلة معها"]
    b4 --> b5["واقع الترحيل ترتيب bitness والاعتماد الخارجي"]

الشكل 10: في ترحيل 64 بت يسهل أن يصير الاعتماد الخارجي مشكلة قبل الشيفرة.

4.4 لا يناسب التنفيذ غير المراقب أو التشغيل على خادم

هذه نقطة مهمّة جدّاً. Microsoft تنصّ صراحة على أنّها لا توصي بأتمتة تطبيقات Office من جانب الخادم ولا تدعمها. صُمِّم Office بافتراض سطح مكتب تفاعلي وملفّ تعريف مستخدم، وقد يحدث عدم استقرار أو deadlock في بيئة غير مراقبة.⁶

لذلك تكوين من هذا النوع أقرب إلى الخطر.

• تشغيل Excel من خدمة Windows
• أتمتة Office من ASP.NET أو DCOM
• تدوير Excel غير المرئي طويلاً على جدولة المهام
• إلقاء توليد التقارير على Excel على الخادم

«يعمل أحياناً» يحدث. لكن العمل شيء، والتكوين الذي يمكن دعمه شيء آخر.

إن لزم التنفيذ غير المراقب، فما ينبغي الشكّ فيه أوّلاً ليس VBA بل تكوين تشغيل تطبيق Excel نفسه.

flowchart TB
    accTitle: سبب عدم الملاءمة للتنفيذ غير المراقب أو التشغيل على خادم
    accDescr: مخطّط يبيّن أن Office صُمِّم بافتراض سطح مكتب تفاعلي وملفّ تعريف مستخدم، وأن أتمتة جانب الخادم غير موصى بها ولا مدعومة، وقد يحدث عدم استقرار أو deadlock في بيئة غير مراقبة، فما ينبغي الشكّ فيه ليس VBA بل تكوين تشغيل تطبيق Excel نفسه.
    u1["تكوين يشغّل Excel من خدمة أو دفعة"] --> u2["Office مصمَّم بافتراض سطح مكتب تفاعلي"]
    u2 --> u3["قد يحدث عدم استقرار أو deadlock في بيئة غير مراقبة"]
    u3 --> u4["أتمتة جانب الخادم خارج التوصية والدعم"]
    u4 -.-> u5["ما ينبغي الشكّ فيه ليس VBA بل تكوين تشغيل Excel"]

الشكل 11: «يعمل أحياناً» و«تكوين يمكن دعمه» مختلفان؛ في التنفيذ غير المراقب اشِكّ في التكوين نفسه.

4.5 يسهل أن يصير غير مواتٍ للصيانة والاختبار وإدارة الفروق

يسهل أن تنغلق شيفرة VBA داخل المصنّف أو ملفّ Access. نتيجة لذلك يسهل حدوث مشكلات من هذا النوع.

• يصير غامضاً أيّ ملفّ هو الأصل
• تتفرّق المسؤوليّة على النماذج والأوراق والوحدات القياسيّة
• تنحرف إعدادات الإشارة واعتماد ActiveX حسب البيئة
• يصعب مراجعة الشيفرة وتأكيد الفروق
• يصعب صنع اختبار وحدة
• عنوان خلية Excel نفسه يتصلّب كمواصفة

هذه ليست مشكلة لغة VBA وحدها، بل مشكلة بنية «حمل منطق العمل داخل ملفّ Office». في أتمتة صغيرة قد لا تصير مشكلة كبيرة، لكن عند التحوّل إلى نظام عمل تظهر فجأة.

flowchart TB
    accTitle: مشكلة بنية حمل المنطق داخل ملفّ Office
    accDescr: مخطّط يبيّن أن VBA يسهل أن تنغلق شيفرته داخل المصنّف أو ملفّ Access، فيصير الأصل غامضاً وتتفرّق المسؤوليّة ويصعب تأكيد الفروق والاختبار، وأن ذلك لا يبرز في أتمتة صغيرة لكن يظهر فجأة عند التحوّل إلى نظام عمل.
    k1["تنغلق الشيفرة داخل ملفّ Office"] --> k2["الأصل غامض والمسؤوليّة متفرّقة"]
    k1 --> k3["يصعب تأكيد الفروق والاختبار"]
    k2 --> k4["لا يبرز في أتمتة صغيرة"]
    k3 --> k4
    k4 --> k5["يظهر فجأة عند التحوّل إلى نظام عمل"]

الشكل 12: ليست اللغة بل بنية «حمل منطق العمل داخل الملفّ» هي التي تولّد المشكلة.

4.6 إن وُجد اعتماد على VBScript فانتباه منفصل لازم

في 2025 أُعلن في Microsoft 365 Developer Blog أن الإيقاف التدريجي لـ VBScript على Windows قد يؤثّر أيضاً في مشاريع VBA. خصوصاً حالة تشغيل .vbs خارجي وحالة الاعتماد على إشارة VBScript.RegExp ضمن نطاق التأثير.¹⁰

في الوقت نفسه تمضي Microsoft أيضاً في معالجة بإدراج صنف RegExp افتراضيّاً في VBA في Office لـ Windows من Microsoft 365 Version 2508 (Build 19127.20154) فما فوق.¹⁰

هل يتأثّر أصلك يُحكَم بالبحث عن النقاط الثلاث التالية. بحث قائمة «تحرير» في VBE جائز، وgrep على نصّ مُخرَج إلى .bas / .cls جائز.

قائمة إعدادات الإشارة تُؤكَّد من «أدوات» ثم «مراجع» في VBE.

بالنسبة إلى RegExp من هذه، كما سبق، تمضي المعالجة بإدراج صنف RegExp افتراضيّاً في جانب VBA في Office لـ Windows من Microsoft 365 Version 2508 (Build 19127.20154) فما فوق.¹⁰ الأثقل تأثيراً هو نمط السطر الثالث «تشغيل .vbs خارجي»، وهنا يلزم النظر في تقريب المعالجة نفسها إلى جانب VBA أو إلى أساس تشغيل آخر. عند صنع سجلّ الأصول (8.1) سجّل هذه الثلاث معها حتى لا يتكرّر العمل.

المهم هنا أن إيقاف VBScript وإيقاف VBA ليسا الحديث نفسه. ليس حديث اختفاء VBA نفسه، بل الأدق الفهم بأن بعضاً من الاعتماد الخارجي المتدلّي من VBA يحتاج مراجعة.

flowchart TB
    accTitle: علاقة إيقاف VBScript بـ VBA
    accDescr: مخطّط يبيّن أن الإيقاف التدريجي لـ VBScript على Windows قد يؤثّر في حالة تشغيل .vbs خارجي أو الاعتماد على إشارة VBScript.RegExp، وأن RegExp تمضي معالجته بإدراجه افتراضيّاً في VBA في Office الجديد، وأنّه ليس الحديث نفسه عن إنهاء VBA ككلّ.
    w1["الإيقاف التدريجي لـ VBScript"] --> w2["الاعتماد على تشغيل .vbs خارجي"]
    w1 --> w3["الاعتماد على VBScript.RegExp"]
    w2 --> w4["النظر في التقريب إلى أساس تشغيل آخر"]
    w3 -.-> w5["Office الجديد يدرجه افتراضيّاً في VBA"]
    w1 -.-> w6["حديث منفصل عن إنهاء VBA ككلّ"]

الشكل 13: ما يتأثّر هو الاعتماد المتدلّي من VBScript فقط، لا إيقاف VBA نفسه.

5. هل سيتعذّر استخدام VBA قريباً

أوّلاً، ليس حديث «يتعذّر الكلّ من الغد». لكنّه أيضاً ليس عصر «يُستخدم في أيّ موضع ولأيّ غرض».

على الأقل في قراءة المعلومات الرسميّة من Microsoft، الاتجاه الظاهر بقوّة الآن هو التالي.

• VBA كتوسيع لـ Office سطح المكتب يستمر في الوجود¹
• جانب الويب / متعدّد المنصّات يفرّق استخدام Office Scripts وOffice Add-ins⁴⁵⁹
• أمان توزيع الماكرو يُعامَل بصرامة أكبر من السابق³
• المكوّنات المحيطة مثل اعتماد VBScript قد تتأثّر مستقبلاً¹⁰

علاوة على ذلك، توضّح Microsoft بشأن Office Scripts أن VBA يتمحور حول سطح المكتب، وOffice Scripts موجَّه إلى حلول سحابيّة آمنة ومتعدّدة المنصّات. وفي الوقت نفسه توضّح أيضاً أن نطاق وظائف Excel المتاحة في عميل سطح المكتب أوسع حاليّاً في VBA.⁴

وضع هذين جنباً إلى جنب يعطي رؤية عمليّة جدّاً.

• في التشغيل العميق لـ Excel سطح المكتب ما زال نطاق VBA أوسع
• في المتصفّح / M365 / مسار العمل المشترك أطبيعيّ Office Scripts أو Add-ins
• لذلك ليس «يكفي تغيير الكلّ إلى Office Scripts» ولا «يكفي إبقاء VBA مركزاً إلى الأبد»

مستقبل VBA أطبيعيّ رؤيته كـ اتّضاح الحدود لا الاختفاء.

flowchart TB
    accTitle: اتّضاح الحدود لا الاختفاء
    accDescr: مخطّط يبيّن أن نطاق VBA ما زال أوسع في التشغيل العميق لـ Excel سطح المكتب، وأن Office Scripts أو Add-ins أطبيعيّ في المتصفّح وM365 ومسار العمل المشترك، وأن التغيّر اتّضاح حدود لا جمع الكلّ في أحد الطرفين.
    z1{"أين يُستخدم"}
    z1 -->|"تشغيل عميق لـ Excel سطح المكتب"| z2["نطاق VBA ما زال أوسع"]
    z1 -->|"متصفّح / M365 / مسار عمل مشترك"| z3["Office Scripts أو Add-ins أطبيعيّ"]
    z2 --> z4["اتّضاح الحدود"]
    z3 --> z4

الشكل 14: ليس «الكلّ إلى Office Scripts» ولا «VBA مركزاً إلى الأبد»، بل الحدود تتحدّد.

6. حالات ينبغي استبدالها / حالات لا يلزم استبدالها

نضع أوّلاً جدول حكم تقريبي لكن نافع.

التهجين في السطر الثاني من الجدول يُستخدم في هذه المقالة بمعنى «إبقاء Excel / Access مدخل UI وتقرير، وإخراج منطق العمل والإدخال/الإخراج وحدهما إلى وحدة تشغيل خارجيّة». الفرق عن الاستبدال الشامل هو عدم تغيير الشاشة والتشغيل الظاهرَين للمستخدم. الشكل المحدّد في 7.1.

المهم في هذا الجدول أن محور حكم الاستبدال ليس «لأن VBA قديم». ما ينبغي النظر إليه حقّاً هو بيئة التشغيل، والتشغيل اليومي، والتوزيع، والاعتماد، والتدقيق، وقابلية التوسيع.

flowchart TB
    accTitle: محور حكم الاستبدال
    accDescr: مخطّط يبيّن أن محور حكم الاستبدال ليس «لأن VBA قديم» بل عناصر بيئة التشغيل والتشغيل اليومي والتوزيع والاعتماد والتدقيق وقابلية التوسيع، وأن التهجين يخرج المنطق والإدخال/الإخراج دون تغيير الشاشة والتشغيل الظاهرَين للمستخدم.
    j0["لأن VBA قديم"] -.-> j1["لا يُجعَل محور حكم"]
    j2["المحاور التي ينبغي رؤيتها حقّاً"] --> j3["بيئة التشغيل والتشغيل اليومي والتوزيع"]
    j2 --> j4["الاعتماد والتدقيق وقابلية التوسيع"]
    j3 --> j5["اختيار الإبقاء / التهجين / الإخراج"]
    j4 --> j5

الشكل 15: محور الحكم ليس القِدَم بل بيئة التشغيل والتشغيل اليومي والتوزيع والاعتماد والتدقيق وقابلية التوسيع.

7. وجهات الاستبدال الواقعيّة

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

الأسهل تفويته عمود «الافتراض والترخيص». Office Scripts خصوصاً شروطه واضحة، فنرتّبه منفرداً في 7.3.

7.1 أبقِ Excel وأخرج المحتوى وحده إلى .NET أو عمليّة أخرى

الأكثر واقعيّة والأصعب فشلاً هو هذا.

• مدخل الشاشة والتقرير يبقى Excel / Access
• الأزرار ونماذج الإدخال تبقى مؤقّتاً كما هي
• لكن منطق العمل وHTTP والتشفير وCSV / JSON والحساب الثقيل ومعالجة الملفّات تُخرَج
• يُقرَّب VBA إلى «جسر» و«تشغيل UI» فقط

مزيّة هذا التكوين أن مظهر المستخدم وتشغيله يصعب كسرهما. يمكن التقدّم أوّلاً باتجاه ترقيق المسؤوليّة بدل الاستبدال الشامل.

flowchart TB
    accTitle: تكوين هجين يُبقي Excel ويخرج المحتوى وحده
    accDescr: مخطّط يبيّن أن إبقاء مدخل الشاشة والتقرير Excel أو Access، وإخراج منطق العمل وHTTP والتشفير والحساب الثقيل ومعالجة الملفّات إلى .NET أو عمليّة أخرى، وتقريب VBA إلى جسر وتشغيل UI فقط، يرقّق المسؤوليّة دون كسر مظهر المستخدم وتشغيله.
    x1["مدخل الشاشة والتقرير يبقى Excel / Access"] --> x2["يُقرَّب VBA إلى جسر وتشغيل UI فقط"]
    x2 --> x3["المنطق الثقيل والإدخال/الإخراج إلى .NET أو عمليّة أخرى"]
    x3 -.-> x4["لا يُكسَر مظهر المستخدم وتشغيله"]

الشكل 16: الأصعب فشلاً هو إبقاء المدخل وإخراج المحتوى وحده.

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

• كيف تستخدم DLL الخاصّة بـ .NET 8 من VBA بـ early binding عبر COM و dscom

«قبل إعادة الكتابة الكاملة، أخرج المواضع الثقيلة أوّلاً» موجَّه جدّاً إلى الممارسة.

7.2 للتنفيذ غير المراقب وتوليد التقارير قرِّب إلى توليد الملفّ مباشرة لا أتمتة تطبيق Office

إن أردت توليد تقارير Excel بالجملة في دفعة ليليّة أو خدمة، فما ينبغي الشكّ فيه أوّلاً ليس «هل VBA قديم» بل تشغيل تطبيق Excel نفسه.

Microsoft لا توصي بـ Office Automation من جانب الخادم. بدلاً من ذلك توصي بطريقة التعامل مع ملفّ Office مباشرة بتنسيق Open XML وما شابه.⁶

أي إن كان المتطلّب:

• صنع .xlsx
• إخراج تقرير نمطي بالجملة
• التحويل إلى PDF
• التدوير في دفعة ليليّة

فالمحور الذي ينبغي اختياره ليس هل تشغّل Excel بل هل تجمّع ملفّ Excel.

flowchart TB
    accTitle: توليد التقارير غير المراقب إلى توليد الملفّ مباشرة
    accDescr: مخطّط يبيّن أن ما ينبغي الشكّ فيه أوّلاً عند توليد التقارير بالجملة في دفعة ليليّة أو خدمة هو تشغيل تطبيق Excel نفسه، وأن Office Automation من جانب الخادم غير موصى به، وأن تجميع ملفّ Office مباشرة بتنسيق Open XML وما شابه هو الاتجاه الموصى به.
    y1["توليد تقارير بالجملة دون مراقبة"] --> y2{"بأيّ محور تفكّر"}
    y2 -.->|"غير موصى به"| y3["تشغيل تطبيق Excel"]
    y2 -->|"الاتجاه الموصى به"| y4["تجميع الملفّ مباشرة بـ Open XML وما شابه"]

الشكل 17: في متطلّب التنفيذ غير المراقب اختر «تجميع الملفّ» لا «تشغيل Excel».

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

• كيف تبني إخراج تقارير Excel - دليل قرار عمليّ بين COM Automation وOpen XML والمقاربة المعتمدة على القوالب والمقايضات

7.3 لمسار العمل على Microsoft 365: Office Scripts + Power Automate

إن كان العمل قد مال بالفعل إلى OneDrive / SharePoint / Teams / Outlook / Forms، يصير Office Scripts مرشّحاً قويّاً.

توضّح Microsoft أن Office Scripts موجَّه إلى حلول سحابيّة آمنة ومتعدّدة المنصّات. كذلك بالجمع مع Power Automate يمكن أتمتة معالجة Excel بمحفّز بريد أو نموذج أو جدولة.⁴¹¹

لكن قبل ذلك يلزم تأكيد شروط الاستخدام. هذه هي افتراض التكلفة والبيئة نفسه، وستؤثّر حتماً لاحقاً.¹²¹³

أي أن Office Scripts ليس «بديلاً مجّانيّاً مرافقاً لـ VBA». مقارنة بتشغيل توزيع .xlsm محلّي، يزداد افتراض OneDrive / SharePoint وترخيص M365. تقرير «الترحيل إلى Office Scripts» مع تفويت ذلك يعيد الحديث في منتصف الترحيل إلى تدبير الترخيص.

flowchart TB
    accTitle: الافتراضات التي تُؤكَّد أوّلاً عند الترحيل إلى Office Scripts
    accDescr: مخطّط يبيّن أن Office Scripts ليس بديلاً مجّانيّاً مرافقاً لـ VBA، وأن افتراض OneDrive أو SharePoint وترخيص M365 يزداد مقارنة بتشغيل توزيع .xlsm محلّي، فتقرير الترحيل مع تفويت ذلك يعيد الحديث في المنتصف إلى تدبير الترخيص.
    o1["تشغيل توزيع .xlsm محلّي"] --> o2["النظر في الترحيل إلى Office Scripts"]
    o2 --> o3["يزداد افتراض OneDrive / SharePoint وترخيص M365"]
    o3 -->|"أكّد أوّلاً"| o4["ادمج الافتراض في خطّة الترحيل"]
    o3 -.->|"إن فوّت"| o5["يعود الحديث في المنتصف إلى تدبير الترخيص"]

الشكل 18: Office Scripts ليس «بديلاً مجّانيّاً لـ VBA»؛ تأكيد الشروط أوّلاً.

بعد ذلك الجانب الوظيفي أيضاً ليس شاملاً.

• Office Scripts لا يدعم أحداث مستوى Excel
• التشغيل أساساً بدء يدوي أو استدعاء من Power Automate⁴
• ربط Power Automate يحتاج ترخيص أعمال لـ Microsoft 365¹¹
• لإجراء Run script قيود مثل 1,600 مرّة لكلّ مستخدم في اليوم و120 ثانية للمعالجة المتزامنة¹²

أي أن الأدق رؤية Office Scripts كـ مكوّن أتمتة على M365 لا كـ «بديل لـ VBA».

flowchart TB
    accTitle: كيف يُشغَّل Office Scripts
    accDescr: مخطّط يبيّن أن Office Scripts لا يدعم أحداث مستوى Excel، وأن التشغيل أساساً بدء يدوي أو استدعاء من Power Automate، مع قيود على عدد الاستدعاءات وزمن المعالجة المتزامنة، فالأدق رؤيته كمكوّن أتمتة على M365 لا كبديل لـ VBA.
    a1["Office Scripts"] --> a2["البدء يدوياً"]
    a1 --> a3["الاستدعاء من Power Automate"]
    a1 -.-> a4["لا يدعم أحداث مستوى Excel"]
    a2 --> a5["يُرى كمكوّن أتمتة على M365"]
    a3 --> a5

الشكل 19: نموذج التشغيل يختلف عن VBA الموجَّه بالأحداث؛ يُستخدم كمكوّن أتمتة على M365.

7.4 إن أردت توسيعاً متعدّد المنصّات فـ Office Add-ins

إن أردت توسيع Word وExcel وOutlook وما شابه عبر Windows / Mac / iPad / المتصفّح، فـ Office Add-ins هو المرشّح الأوّل.

الوثائق الرسميّة من Microsoft أيضاً توضّح أن Office Add-ins يمكن بناؤه بـ HTML / CSS / JavaScript، ويعمل عبر منصّات متعدّدة ويناسب التوزيع المركزي.⁵

هذا يناسب متطلّبات من هذا النوع مثلاً.

• ربط بوّابة داخليّة أو نظام أساسي بـ Office
• إخراج الـ UI أو الأمر نفسه في Outlook / Excel / Word
• توزيع من المسؤول لا توزيع ماكرو لكلّ جهاز مستخدم
• مغادرة نموذج توزيع .xlsm المحلّي

الملعب يختلف عن VBA، فيتغيّر الإحساس كثيراً عن كتابة شيفرة داخل Excel. بالمقابل يسهل ترتيب التشغيل والتوزيع.

flowchart TB
    accTitle: الشكل الذي يناسبه Office Add-ins
    accDescr: مخطّط يبيّن أن Office Add-ins يُبنى بـ HTML وCSS وJavaScript، ويعمل عبر Windows وMac وiPad والمتصفّح ويناسب التوزيع المركزي، فيلائم متطلّب مغادرة توزيع ماكرو لكلّ جهاز أو نموذج توزيع .xlsm محلّي.
    d1["البناء بـ HTML / CSS / JavaScript"] --> d2["يعمل على Windows / Mac / iPad / المتصفّح"]
    d2 --> d3["توزيع مركزي من المسؤول"]
    d3 --> d4["مغادرة نموذج توزيع .xlsm المحلّي"]

الشكل 20: إن كان متعدّد المنصّات والتوزيع المركزي متطلّبين، فهذا ملعب Add-ins.

7.5 إن لم يعد Excel / Access هو الـ UI الأصلي، فأخرج إلى تطبيق Windows أو ويب

إن وصل الحال إلى هذا، فأطبيعيّ إعادة البناء كتطبيق من إطالة عمر VBA.

• ازداد تنقّل الشاشات والتحكّم في الصلاحيّات أكثر من اللازم
• المركز قاعدة بيانات وسجلّ تدقيق ومسار موافقة وإدارة مستخدمين
• يوجد ربط بأجهزة خارجيّة أو معالجة طويلة
• صارت خلية Excel أو النموذج بديلاً عن مواصفات العمل
• اختفاء إدارة الحالة عند إغلاق المصنّف نفسه صار مؤلماً

في هذه الحالة، إن كانت الأداة تفترض Windows فأطبيعيّ تطبيق سطح مكتب بـ C# / .NET، وإن اتّسع المستخدمون والأجهزة فأطبيعيّ تطبيق ويب لتصير البنية أوضح.

8. كيف يُتقدَّم في الترحيل المرحلي

أخطر ما في استبدال VBA هو محاولة جمع الكلّ في تقنية جديدة واحدة من البداية. في الممارسة أأمن عموماً أن تُخطى المراحل بالترتيب التالي.

8.1 اصنع أوّلاً سجلّ أصول

ما ينبغي جرده أوّلاً هو الاعتماد أكثر من حجم الشيفرة نفسه.

• أيّ .xlsm / .xlam / .accdb / .mdb موجود
• أيّها مدخل التشغيل الفعلي
• ماذا في إعدادات الإشارة
• ما Declare وDLL الخارجي وCOM / ActiveX / OCX
• كيف هو افتراض 32 بت / 64 بت
• أيّ ماكرو يستخدمه من وبأيّ إجراء
• ما المخرجات (Excel، CSV، PDF، طباعة، إرسال بريد، إلخ)

الاستبدال مع بقاء هذا غامضاً يولّد لاحقاً حادثاً من نوع «ماكرو ظننا أن لا أحد يلمسه كان حيّاً في نهاية الشهر فقط».

flowchart TB
    accTitle: ما يجرده سجلّ الأصول
    accDescr: مخطّط يبيّن أن أوّل الترحيل المرحلي جرد الاعتماد لا حجم الشيفرة، أي أيّ ملفّ مدخل التشغيل الفعلي، وكيف إعدادات الإشارة وDLL الخارجي وافتراض bitness، ومن يستخدم أيّ ماكرو وبأيّ إجراء وماذا يُخرِج، وأن الغموض يولّد حادث ماكرو حيّ في نهاية الشهر فقط.
    r1["جرد الملفّات"] --> r2["جرد الاعتماد (إعدادات الإشارة وDLL وbitness)"]
    r2 --> r3["جرد الاستخدام (من وبأيّ إجراء والمخرج)"]
    r3 -.-> r4["الغموض يولّد حادث ماكرو حيّ في نهاية الشهر فقط"]

الشكل 21: ما يراه السجلّ ليس حجم الشيفرة بل الاعتماد وطريقة الاستخدام.

8.2 اقسم الشيفرة حسب المسؤوليّة

التالي ليس القسمة حسب الملفّ بل حسب المسؤوليّة.

• تشغيل UI لـ Excel / Access
• إدخال وإخراج الورقة
• تخطيط التقرير
• قواعد العمل
• API خارجي / ملفّ / إدخال وإخراج قاعدة بيانات
• معالجة دفعة
• طباعة / توزيع

هذا التقسيم يسهّل رؤية ما يُبقى وما يُرقَّق وما يُخرَج.

8.3 قرّر وجهة الاستبدال حسب المسؤوليّة

تقسيم يسهل التوصية به كالتالي.

• الـ UI وتشغيل الورقة: أبقِ في VBA مؤقّتاً
• منطق العمل: أخرج إلى DLL من .NET أو عمليّة أخرى أو خدمة
• توليد التقارير غير المراقب: قرِّب إلى Open XML أو التوليد المباشر
• مسار عمل M365: Office Scripts + Power Automate
• UI متعدّد المنصّات: Office Add-ins
• مجال صار نظام عمل: افصل إلى تطبيق Windows / ويب

المهم ألّا تُوحَّد وجهة الترحيل في واحدة. محتوى أصل VBA يختلط فيه عادة عدّة مسؤوليّات.

flowchart TB
    accTitle: تقرير وجهة الترحيل حسب المسؤوليّة
    accDescr: مخطّط يبيّن أن قسمة الشيفرة حسب المسؤوليّة لا حسب الملفّ تسهّل رؤية ما يُبقى وما يُرقَّق وما يُخرَج، فيُبقى الـ UI وتشغيل الورقة في VBA مؤقّتاً، ويُخرَج منطق العمل إلى .NET، وتوليد التقارير غير المراقب إلى Open XML، ومسار عمل M365 إلى Office Scripts.
    m1["قسمة الشيفرة حسب المسؤوليّة"] --> m2["يظهر ما يُبقى / يُرقَّق / يُخرَج"]
    m2 --> n1["الـ UI وتشغيل الورقة يُبقيان في VBA مؤقّتاً"]
    m2 --> n2["منطق العمل إلى .NET أو عمليّة أخرى"]
    n1 --> n3["توليد التقارير غير المراقب إلى Open XML"]
    n2 --> n4["مسار عمل M365 إلى Office Scripts"]

الشكل 22: القسمة حسب المسؤوليّة لا حسب الملفّ تجعل وجهات الترحيل متعدّدة طبيعيّاً.

8.4 ثبّت الواجهة أوّلاً

قبل بدء الترحيل أأمن تقرير التالي على الأقل.

• ما الإدخال
• ما الإخراج
• كيف يُرجَع عند الخطأ
• أيّ ورقة وأيّ نطاق مسمّى وأيّ مسار ملفّ يُجعَل عقداً
• في أيّ لحظة تُعدّ النتيجة ثابتة

التقدّم دون تقرير ذلك يجعل عنوان الخلية نفسه API فيسهل الكسر.

8.5 قارن بالتشغيل المتوازي

للتقارير والتجميع خصوصاً، أأمن ألّا تُبدَّل فجأة.

• أخرج نسخة VBA القديمة والتنفيذ الجديد على التوازي
• قارن .xlsx / CSV / PDF المُخرَج
• أكّد فرق التاريخ والتقريب والتنسيق ونطاق الطباعة
• جرّب أيضاً مسار الاستثناء ومسار البيانات الفارغة

حوادث استبدال VBA تحدث عادة لا في «هل يعمل» بل في شكل انحراف الأرقام أو التنسيق بهدوء.

flowchart TB
    accTitle: قارن بالتشغيل المتوازي ثم بدّل
    accDescr: مخطّط يبيّن أن التقارير والتجميع لا تُبدَّل فجأة، بل تُخرَج نسخة VBA القديمة والتنفيذ الجديد على التوازي، ويُؤكَّد فرق التاريخ والتقريب والتنسيق ونطاق الطباعة، وتُجرَّب مسارات الاستثناء والبيانات الفارغة ثم يُبدَّل، لمنع حادث انحراف الأرقام أو التنسيق بهدوء.
    h1["إخراج النسخة القديمة والتنفيذ الجديد على التوازي"] --> h2["مقارنة المخرج (تاريخ وتقريب وتنسيق ونطاق طباعة)"]
    h2 --> h3["تجربة مسار الاستثناء ومسار البيانات الفارغة أيضاً"]
    h3 --> h4["التبديل بعد تأكيد غياب الفرق"]
    h2 -.-> h5["الحادث يحدث بشكل انحراف الأرقام أو التنسيق بهدوء"]

الشكل 23: لا تبدّل فجأة؛ انقل بعد مقارنة مخرجات القديم والجديد على التوازي.

9. إخفاقات شائعة

9.1 البدء بـ «VBA قديم، انقل الكلّ إلى Office Scripts»

Office Scripts قوي، لكن Microsoft نفسها توضّح أن نطاق وظائف Excel سطح المكتب أوسع في VBA. علاوة على ذلك Office Scripts لا يدعم أحداث مستوى Excel.⁴

لذلك فكرة النقل العرضي لماكرو يعتمد بعمق على Excel سطح المكتب خطرة.

9.2 مواصلة تشغيل Excel نفسه رغم التنفيذ غير المراقب

هذا كثير جدّاً. ما دام يعمل يبدو مريحاً، لكن Microsoft لا توصي بأتمتة Office من جانب الخادم.⁶

للدفعة الليليّة أو الخدمة، أأمن التقريب إلى تجميع ملفّ Excel لا تشغيل Excel.

9.3 تغيير الشاشة والتقرير وقواعد العمل كلّها في الوقت نفسه

ما يُخيف حقّاً في استبدال VBA ليس تحويل الشيفرة نفسه بل تفويت مواصفات العمل. في ورقة Excel أو نموذج Access قواعد تشغيل غير مكتوبة في الشيفرة مدفونة بكثرة.

تغيير الكلّ دفعة واحدة يسهّل حادثاً من نوع «المظهر قريب لكن نهاية الشهر وحدها تختلف».

flowchart TB
    accTitle: ما يحدث عند تغيير الكلّ في الوقت نفسه
    accDescr: مخطّط يبيّن أن ما يُخيف حقّاً في استبدال VBA ليس تحويل الشيفرة بل تفويت مواصفات العمل، وأن ورقة Excel أو نموذج Access يدفن قواعد تشغيل غير مكتوبة في الشيفرة، فتغيير الشاشة والتقرير وقواعد العمل كلّها في الوقت نفسه يسهّل حادثاً مظهره قريب ونهاية الشهر فيه تختلف.
    g1["تغيير الشاشة والتقرير وقواعد العمل كلّها في الوقت نفسه"] --> g2["تفويت قواعد تشغيل غير مكتوبة في الشيفرة"]
    g2 --> g3["حادث مظهره قريب ونهاية الشهر فيه تختلف"]
    g2 -.-> g4["المخيف تفويت مواصفات العمل لا تحويل الشيفرة"]

الشكل 24: تغيير الكلّ دفعة واحدة يسهّل تفويت مواصفات العمل خارج الشيفرة.

9.4 تأجيل 32 بت / 64 بت والإشارات الخارجيّة

في قضايا الترحيل، كثيراً ما ينفجر قبل شيفرة VBA نفسها:

• Declare
• DLL خارجي
• COM / ActiveX / OCX
• bitness في Office
• إعدادات الإشارة

تأجيل هذا يجعل نهاية التنفيذ صعبة دفعة واحدة.⁷

9.5 خلط حديث VBScript بحديث VBA

الإيقاف التدريجي لـ VBScript، من جهة VBA، حديث مراجعة بعض الاعتماد. ليس المعنى نفسه لإنهاء VBA ككلّ.¹⁰

خلط هذا يسهّل أن تسير وحدها معلومة داخليّة فضفاضة من نوع «يبدو أن VBA سينتهي».

10. الخلاصة

إن قيل VBA بجملة، فهو لغة توسيع ملتصقة بتطبيقات Office لسطح المكتب. لأتمتة عمل يد المستخدم بجانب Excel أو Access ما زال عمليّاً جدّاً.¹

لكن المهم في الممارسة القادمة هو ألّا يُعامَل VBA كتقنية مركز شاملة.

• إن أردت متصفّحاً / تعدّد منصّات فانظر إلى Office Scripts أو Office Add-ins⁴⁵
• للتنفيذ غير المراقب / معالجة الخادم تجنّب Office Automation⁶
• المنطق الثقيل والربط الخارجي أخرجه إلى .NET أو عمليّة أخرى
• إن صار Excel / Access متعباً كـ UI فأخرج إلى تطبيق Windows أو ويب

الإجابة ليست «استبدل الكلّ» ولا «لا تغيّر شيئاً» بل «اقسم حسب المسؤوليّة ورقِّق على مراحل».

flowchart TB
    accTitle: إجابة الاستبدال
    accDescr: مخطّط يبيّن أن إجابة VBA ليست استبدال الكلّ ولا عدم تغيير شيء، بل القسمة حسب المسؤوليّة والترقيق على مراحل، وأن أأمن الاستبدال أن يُتقدَّم فيه كترتيب لا كترجمة.
    q0{"ماذا نفعل بأصل VBA"}
    q0 -.->|"طرف"| e1["استبدل الكلّ"]
    q0 -.->|"طرف"| e2["لا تغيّر شيئاً"]
    q0 -->|"إجابة عمليّة"| e3["اقسم حسب المسؤوليّة ورقِّق على مراحل"]
    e3 --> e4["تقدّم كترتيب لا كترجمة"]

الشكل 25: الإجابة ليست الطرفين، بل القسمة حسب المسؤوليّة والترقيق على مراحل.

أصل VBA يبدو قديماً إن نُظر إليه على عجل. لكن في الممارسة يمتلئ بـ مواصفات العمل، وإجراءات التشغيل، وتصميم التقارير، واعتياد الميدان.

لذلك أأمن الاستبدال أن يُتقدَّم فيه كـ ترتيب لا كـ ترجمة.

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

• ما هي COM / ActiveX / OCX - دليل عمليّ للفروق والعلاقات بينها
• كيف تستخدم DLL الخاصّة بـ .NET 8 من VBA بـ early binding عبر COM و dscom
• كيف تبني إخراج تقارير Excel - دليل قرار عمليّ بين COM Automation وOpen XML والمقاربة المعتمدة على القوالب والمقايضات

روابط مرجعية

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

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

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

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

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل سيتعذّر استخدام VBA قريباً؟

حتى مارس 2026 على الأقل، لا يظهر في المعلومات الرسميّة من Microsoft إعلان واضح بأن «VBA نفسه سيُنهى قريباً». ما يحدث الآن ليس إلغاءً مفاجئاً شاملاً، بل اتّضاح أماكن الاستخدام وشروطه. تحديداً، لا يمكن إنشاء VBA أو تشغيله أو تحريره في Excel for the web، وتُحظَر ماكروهات الملفّات ذات الأصل من الإنترنت افتراضيّاً. مستقبل VBA أقرب إلى اتّضاح الحدود منه إلى الاختفاء.

هل يكفي ترحيل VBA كلّه إلى Office Scripts؟

لا نوصي بذلك. Microsoft نفسها توضح أن نطاق وظائف Excel المتاحة في عميل سطح المكتب أوسع حاليّاً في VBA، وأن Office Scripts لا يدعم أحداث مستوى Excel. الأدق رؤية Office Scripts لا كبديل لـ VBA بل كمكوّن أتمتة على M365 يُشغَّل مع Power Automate على مصنّفات OneDrive أو SharePoint. وجهة الترحيل تُختار حسب المسؤوليّة.

هل يجوز تشغيل ماكرو Excel دون مراقبة على خادم أو دفعة ليليّة؟

هذا خطر. Microsoft تنصّ صراحة على أنّها لا توصي بأتمتة تطبيقات Office من جانب الخادم ولا تدعمها. صُمِّم Office بافتراض سطح مكتب تفاعلي وملفّ تعريف مستخدم، وقد يحدث عدم استقرار أو deadlock في بيئة غير مراقبة. إن كان توليد التقارير بالجملة متطلّباً، فالموصى به تجميع ملفّ Excel مباشرة بتنسيق Open XML مثلاً، لا تشغيل تطبيق Excel.

كيف يُرحَّل أصل VBA القائم؟

الأأمن الترحيل المرحلي لا جمع الكلّ في تقنية جديدة واحدة من البداية. أوّلاً اصنع سجلّ أصول لملفّات .xlsm والإشارات وDLL الخارجي وافتراض 32 بت / 64 بت، ثم اقسم الشيفرة حسب المسؤوليّة: تشغيل الـ UI، منطق العمل، التقارير، الإدخال/الإخراج. بعد ذلك أبقِ الـ UI وتشغيل الورقة في VBA مؤقّتاً، وانقل منطق العمل إلى DLL من .NET أو عمليّة أخرى، وتوليد التقارير غير المراقب إلى Open XML، ومسار عمل M365 إلى Office Scripts. للتقارير والتجميع قارن مخرجات القديم والجديد على التوازي ثم بدّل.

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

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

غو كومورا

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

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