إقامة تطبيقات Windows في علبة النظام والإشعارات المنبثقة ── مطبات NotifyIcon وكيفية اختيار AppNotification

«أريد إخطار المستخدم بهدوء عند انتهاء معالجة» — «أريد أن تستمر المراقبة حتى بعد إغلاق النافذة» ── في تطبيقات الأعمال، الإقامة في علبة النظام (منطقة الإشعارات) والإشعارات المنبثقة (Toast) مطلبان كلاسيكيان يظهران معاً غالباً. لكن بمجرد التنفيذ تبدأ مشكلات صغيرة بالظهور واحدة تلو الأخرى: تطبيق كان يُفترض أن يُغلق لا يستطيع الخروج فعلاً، أو تختفي الأيقونة بعد إعادة تشغيل Explorer، أو إشعار منبثق كان يعمل أثناء التطوير لا يظهر أبداً لدى العميل.

فضلاً عن ذلك، تُعد الإشعارات المنبثقة مجالاً استمر فيه تعاقب أجيال الواجهة منذ عصر UWP. ليس نادراً أن تبحثوا فتجدوا كوداً تجريبياً يستخدم، بمعايير اليوم، واجهة صارت في أفضل الأحوال في وضع الصيانة فقط. يرتّب هذا المقال تصميم الإقامة في العلبة عبر NotifyIcon، وكيفية اختيار واجهة الإشعارات المنبثقة اعتباراً من عام 2026، مع المطبات العملية التي يُرجَّح أن تصادفوها.

كيفية قراءة هذا المقال

أحد عشر فصلاً وطويل، لذا نعرض مداخل حسب الغرض. لا يلزم القراءة من الرأس بالترتيب.

المصطلحات المستخدمة في هذا المقال

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

• أساس الإقامة في العلبة ما يزال System.Windows.Forms.NotifyIcon. لن تظهر الأيقونة ما لم تُعيَّن Icon ويُضبط Visible = true (القيمة الافتراضية false). يمكن أن يصل نص تلميح الأداة Text إلى 127 حرفاً في .NET 6 وما بعده (63 حرفاً قبل ذلك).⁴⁵
• لا يوجد في WPF أي عنصر تحكّم مكافئ لـ NotifyIcon. ينص جدول المقارنة الرسمي صراحة على «لا يوجد عنصر تحكّم مكافئ». تفعيل كل من UseWPF وUseWindowsForms في ملف csproj واستخدام NotifyIcon الخاص بـ WinForms هو الحد الأدنى للإعداد.⁶⁷
• «إبقاء التطبيق في العلبة حتى عند النقر على زر الإغلاق» يُنفَّذ بضبط e.Cancel = true في FormClosing واستدعاء Hide(). قدّموا دائماً وسيلة خروج منفصلة وصريحة (عنصر «إنهاء» في قائمة العلبة)، وتحقّقوا من CloseReason حتى لا تعيقوا أبداً إيقاف تشغيل النظام.⁸
• واجهة الإشعارات المنبثقة واضحة التوصية اعتباراً من عام 2026. بغض النظر عما إذا بنيتم تطبيق WinForms أو WPF أو تطبيقاً غير مُعبَّأ، فإن AppNotificationManager الخاص بـ Windows App SDK (حزمة NuGet: Microsoft.WindowsAppSDK) هو الموصى به. أما Windows.UI.Notifications فهي «للصيانة فقط»، ومكوّن الإشعارات في Community Toolkit أُرشف.⁹¹⁰
• تعمل AppNotification الخاصة بـ Windows App SDK حتى من ملف exe عادي بلا هوية حزمة. تتولّى AppNotificationManager.Default.Register() تلقائياً تسجيل خادم COM والمعالجة المكافئة لـ AUMID، لذا لم تعد بحاجة لإعداد اختصار في قائمة ابدأ كما كان مطلوباً في الأجيال الأقدم. مع ذلك، الإشعارات من العمليات المرفوعة الصلاحيات (مسؤول) غير مدعومة.¹¹¹²¹³
• الإشعار المنبثق ليس وسيلة «مضمونة الوصول» إلى المستخدم. أثناء تفعيل عدم الإزعاج (Focus Assist) لا تظهر اللافتة وتذهب مباشرة إلى مركز الإشعارات، ويمكن للمستخدم إيقاف الإشعارات كلياً من الإعدادات. يجب ألا يفترض تصميمكم أن «الإشعار المنبثق قد ظهر» كشرط مسبق لتدفق عمل الأعمال.¹⁴¹⁵
• لا يمكن لخدمة Windows إرسال إشعارات منبثقة (الجلسة 0 لا تحتوي على واجهة مستخدم). النهج القياسي هو وضع وكيل مقيم في العلبة ضمن جلسة المستخدم والتنسيق معه عبر IPC.³

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

2. أساسيات الإقامة في العلبة عبر NotifyIcon

المكوّن الذي يضع أيقونة في منطقة الإشعارات عند الطرف الأيمن من شريط المهام هو System.Windows.Forms.NotifyIcon. تستخدمه التطبيقات التي تستمر في العمل في الخلفية مدخلاً لعرض الحالة وقائمة التشغيل.⁴

private NotifyIcon _trayIcon = null!;

private void InitializeTrayIcon()
{
    var menu = new ContextMenuStrip();
    menu.Items.Add("فتح", null, (_, _) => ShowMainWindow());
    menu.Items.Add(new ToolStripSeparator());
    menu.Items.Add("إنهاء", null, (_, _) => ExitApplication());

    _trayIcon = new NotifyIcon
    {
        Icon = Properties.Resources.AppIcon, // Iconは必須。未設定だと表示されない
        Text = "أداة مراقبة الطلبات ── قيد التشغيل",     // ツールチップ(.NET 6+で最大127文字)
        ContextMenuStrip = menu,
        Visible = true                        // 既定はfalse。trueにして初めて表示される
    };
    _trayIcon.DoubleClick += (_, _) => ShowMainWindow();
}

النقاط التي ينبغي تثبيتها ثلاث.

• لا تظهر الأيقونة إلا باجتماع Icon وVisible = true. القيمة الافتراضية لـ Visible هي false.⁴
• لـ Text حد طول. من .NET 6 فما بعده الحد 127 حرفاً، وفي .NET 5 وما قبله و.NET Framework 63 حرفاً، وإذا تجاوز وقع ArgumentException. التنفيذ الذي يحشو الحالة في تلميح الأداة أكثر من اللازم يصير سبباً لسقوط مفاجئ باستثناء.⁵¹⁶
• تُربَط قائمة النقر الأيمن بـ ContextMenuStrip. كثيراً ما تكون أيقونة العلبة المدخل الوحيد الظاهر للمستخدم، لذا أعدّوا «فتح» و«إنهاء» كحد أدنى.¹⁷

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

3. تصميم «يبقى في العلبة حتى عند الإغلاق»، ومسار الإنهاء الصحيح

الحركة الكلاسيكية للتطبيق المقيم هي «حتى عند الإغلاق بزر × لا تنتهي العملية، بل تبقى في العلبة». التنفيذ نفسه يُكتب بسهولة بإلغاء FormClosing، لكن الكتابة العشوائية تؤدّي إلى حادثتين: اختفاء وسيلة إنهاء التطبيق، وإعاقة إيقاف تشغيل Windows.

private bool _exitRequested;

protected override void OnFormClosing(FormClosingEventArgs e)
{
    // ユーザーが×を押しただけなら、閉じずに隠す
    if (!_exitRequested && e.CloseReason == CloseReason.UserClosing)
    {
        e.Cancel = true;
        Hide();
        return;
    }
    // 「終了」メニュー経由、またはOSシャットダウン等はそのまま閉じる
    base.OnFormClosing(e);
}

private void ExitApplication()
{
    _exitRequested = true;
    _trayIcon.Visible = false;
    _trayIcon.Dispose();
    Close();
}

يقع FormClosing قبل إغلاق النموذج، ويمكن إلغاء الإغلاق بـ e.Cancel = true. تحقّقوا عندئذ حتماً من CloseReason. السلوك الصحيح إلغاء الإغلاق فقط عند UserClosing (عملية المستخدم)، وعدم إلغاء الإغلاق الناشئ عن نظام التشغيل مثل WindowsShutDown.⁸¹⁸

في WPF الفكرة نفسها، ونمط ضبط e.Cancel = true في Window.Closing ثم Hide() وارد كما هو في الوثائق الرسمية.¹⁹

يُلاحظ أن التطبيق المقيم بطبيعته يجاور مشكلة «التشغيل المزدوج يعالج الحدث نفسه مرتين». منع التشغيل المتعدد مرتَّب في «منع التشغيل المتعدد لتطبيقات Windows ── Mutex مسمّى والتفعيل عند التشغيل المزدوج». أما طريقة بناء محتوى التطبيق المقيم (حلقة المراقبة أو المعالجة الدورية) فأساسها «لماذا نستخدم .NET Generic Host وBackgroundService في تطبيقات سطح المكتب».

4. الإقامة في العلبة في تطبيقات WPF

لا يوجد في WPF عنصر تحكّم مكافئ لـ NotifyIcon. هذا نقص في المواصفات مذكور صراحة في جدول المقارنة الرسمي «عناصر تحكّم WinForms وما يكافئها في WPF» بعبارة «No equivalent control».⁶

الخياران الواقعيان اثنان.

الأول مجرد إيراد الخاصيتين معاً في ملف مشروع بأسلوب SDK.⁷

<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>
  <UseWPF>true</UseWPF>
  <UseWindowsForms>true</UseWindowsForms>
</PropertyGroup>

يمكن استخدام System.Windows.Forms.NotifyIcon بـ new عادي من Application في WPF. تصير القائمة وحدها WinForms (ContextMenuStrip)، لكن لقائمة علبة هذا القدر لا يشكّل مشكلة عملية في العادة.

5. ثلاثة مطبات لأيقونة العلبة

5.1. الأيقونة تدخل افتراضياً في «الأيقونات المخفية» ── لا يمكن فرض العرض

طلب إبقاء أيقونتكم ظاهرة دائماً في شريط المهام يظهر حتماً، لكن لا يمكن تحقيقه من البرنامج. تنص الوثائق الرسمية على أن الأيقونة تُضاف افتراضياً إلى منطقة الفيض (الأيقونات المخفية)، وأن من يقرّر الترقية إلى منطقة الإشعارات (العرض الدائم) هو المستخدم وحده.¹

في Windows 11 يشغّل المستخدم التبديل لكل تطبيق من «الإعدادات ← التخصيص ← شريط المهام ← أيقونات علبة النظام الأخرى». إذا كان العرض الدائم مهماً تشغيلياً، فالتعامل الصحيح كتابة «فعّلوا هذا الإعداد» في دليل التثبيت أو التعليمات.

اكتبوا في الدليل المسار الكامل للقائمة حتى يمكن الإرشاد عبر الهاتف. مثال النص كما يلي.

1. انقروا بالزر الأيمن في موضع فارغ من شريط المهام، واختاروا «إعدادات شريط المهام».
2. في الشاشة المفتوحة افتحوا «أيقونات علبة النظام الأخرى».
3. ابحثوا عن هذا التطبيق في القائمة، وشغّلوا المفتاح.

※ إذا لم تظهر الأيقونة، اضغطوا زر «^» (شكل الجبل) في يمين شريط المهام فتظهر الأيقونات المخفية مؤقتاً.

5.2. إعادة تشغيل Explorer تخفي الأيقونة ── TaskbarCreated

عندما يعيد Explorer بناء شريط المهام بعد انهيار أو إعادة تشغيل، تختفي أيقونات العلبة المسجَّلة. يبث الغلاف رسالة TaskbarCreated إلى كل النوافذ ذات المستوى الأعلى عند إنشاء شريط المهام، واستقبالها ثم إعادة تسجيل الأيقونة قاعدة على مستوى Win32.²⁰

يعالج NotifyIcon في WinForms هذه الرسالة داخلياً ويعيد التسجيل تلقائياً، لذا لا يلزم الوعي بها عادة. عند استدعاء Shell_NotifyIcon بأنفسكم عبر P/Invoke (أو عند صيانة تطبيق أصلي يملك أيقونة علبة)، تحقّقوا من وجود معالجة إعادة التسجيل هذه. عرض «بعد إعادة تشغيل Explorer تختفي الأيقونة وحدها والعملية حية» يكاد يكون هذا.

5.3. نسيان Dispose يُبقي الأيقونة

على مستوى Win32 يلزم حذف أيقونة العلبة صراحة (NIM_DELETE) عندما تصير غير لازمة، وفي WinForms يتولّى ذلك NotifyIcon.Dispose().¹ احرصوا على مرور Visible = false ثم Dispose() حتماً في مسار الإنهاء. إذا لم تُحذف لأن العملية انتهت بشكل غير طبيعي مثلاً، تبقى أيقونة شبح حتى يمرّر مؤشر الفأرة فوقها؛ مشهد يراه مطوّر التطبيقات المقيمة مرة على الأقل.

كما في كود الفصل 3، الشكل الآمن إنهاء أيقونة العلبة في معالجة قائمة «إنهاء» ثم استدعاء Close().

6. الإشعارات المنبثقة ── أي واجهة تُستخدم

الإشعار المنبثق إشعار يظهر كلافته في أسفل يمين الشاشة ويبقى في مركز الإشعارات. طريقة إخراجه من تطبيق سطح المكتب تعاقبت أجيالها على مدى عشر سنوات، وتبقى عيّنات قديمة كثيرة في نتائج البحث. الترتيب اعتباراً من 2026 كما يلي.⁹

تكميلان اثنان.

• ShowBalloonTip في خانة «واجهة قديمة لكنها ما تزال حية». في Windows 10 يُرسم البالون كـ Toast ويبقى في مركز الإشعارات حتى يُغلق. أما في Windows 11 فيصير عرضاً مؤقتاً أقرب إلى البالون التقليدي، وبعد اختفائه لا يبقى في مركز الإشعارات. تحديد مدة العرض (timeout) يُتجاهل حالياً ويتبع إعدادات إمكانية الوصول في جانب نظام التشغيل. يكفي لإشعار خفيف بتغيّر حالة تطبيق مقيم في العلبة، لكن اذكروا أنه لا ينفع في Windows 11 إن أردتم إبقاء سجلاً في مركز الإشعارات.²¹
• في الطريقة الكلاسيكية لاستخدام Windows.UI.Notifications الخام من تطبيق سطح مكتب قيد شهير: لن يظهر Toast ما لم يُسجَّل اختصار بـ AUMID (AppUserModelID) في قائمة ابدأ.²² ما أزال هذا العناء هو AppNotification في الفصل التالي.

يمكن رسم خط وظيفي لمدى «جائز للاستخدام البسيط» في الجدول. إذا استُوفيت الخمسة التالية كلها يكفي ShowBalloonTip، ولا حاجة لزيادة تبعية Windows App SDK.

• التطبيق يملك أيقونة علبة أصلاً (البالون إشعار تابع لأيقونة العلبة، فهذا شرط)
• الإشعار لا يحتاج أزرار تشغيل أو حقل إدخال. يكفي أن يقدّم نافذة التطبيق إلى الأمام عند النقر
• لا حاجة لإبقاء سجل في مركز الإشعارات. في Windows 11 لا يبقى، فلا يصلح لغرض «المراجعة لاحقاً»²¹
• لا حاجة لشريط تقدّم أو تحديث محتوى إشعار معروض
• الإشعار مساعدة «إن لُوحظ أمكنت الاستجابة أسرع»، والعمل يدور حتى إن فات

في المقابل، إذا انطبق أي واحد مما يلي فاستخدموا AppNotification في الفصل 7 بلا تردّد.

مؤشر الحيرة واحد: «هل تريدون أن يشغّل المستخدم شيئاً تجاه ذلك الإشعار». إن كان للقراءة فقط فبالون، وإن كان للضغط فـ AppNotification.

7. الحد الأدنى لتنفيذ Windows App SDK AppNotification

واجهة إشعارات تطبيقات Windows App SDK تعمل حتى من ملف exe عادي غير معبّأ، بلا معرّف حزمة.¹¹ غير أن الأمر ليس «أدخلوا NuGet وانتهى»، بل لكل من جانب التطوير وجانب التوزيع مقدّمات. ننظر إليها بالترتيب.

7.1. إعداد جانب المشروع ── NuGet وcsproj

المقدّمة الرسمية ثلاث نقاط: أن يكون المشروع WPF أو WinForms على .NET 6 فما بعده، وأن يكون المشروع مُعدّاً لاستدعاء واجهات WinRT، وأن يكون مُعدّاً لاستخدام Windows App SDK.¹²

ما يُفعل أمران. أولاً أضيفوا حزمة NuGet Microsoft.WindowsAppSDK (من Visual Studio: «أدوات ← مدير حزم NuGet ← إدارة حزم NuGet للحل»). تضم هذه الحزمة حزماً فرعية لمكوّنات Windows App SDK، وتوصي الوثائق الرسمية أيضاً بإدخال الحزمة الرئيسة أولاً.²

ثم حرّروا csproj. بإضافة حصة Windows App SDK إلى مثال WPF+WinForms في الفصل 4 يصير الشكل التالي.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <!-- لتستدعي WinRT API ضمّن إصدار Windows في TFM -->
    <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
    <UseWPF>true</UseWPF>
    <UseWindowsForms>true</UseWindowsForms>
    <!-- تطبيق غير مُعبَّأ (ليس MSIX): هيّئ زمن التشغيل تلقائياً عند البدء -->
    <WindowsPackageType>None</WindowsPackageType>
  </PropertyGroup>

  <ItemGroup>
    <!-- الإصدار هو ما اخترته في مدير حزم NuGet -->
    <PackageReference Include="Microsoft.WindowsAppSDK" Version="(الإصدار المستقر المختار)" />
  </ItemGroup>
</Project>

<WindowsPackageType>None</WindowsPackageType> هي النقطة الحاسمة. التطبيق غير المُعبَّأ يجب أن يهيّئ زمن التشغيل قبل استخدام ميزات Windows App SDK، وكتابة هذه الخاصية تفعّل التهيئة التلقائية عند التشغيل (auto-initialization). عند البناء تُضاف إلى المشروع MddBootstrapAutoInitializer.cs وWindowsAppSDK-VersionInfo.cs. فقط عند الحاجة إلى تحكّم أدق تستدعون واجهة التمهيد مباشرة بدل التهيئة التلقائية.²

7.2. إدخال زمن التشغيل لدى جهة التوزيع

هنا ما يسهل إغفاله. في حالة التطبيق غير المُعبَّأ، مسؤولية إيصال زمن تشغيل Windows App SDK إلى جهاز المستخدم تقع على جهة التوزيع.²³ توزيع exe وحده لا يكفي للتشغيل.

كشرط، يحتاج التطبيق غير المُعبَّأ أيضاً إلى حزمة Visual C++ القابلة لإعادة التوزيع.²³ طريقتا الإدخال اثنتان.

المثبّت بلا واجهة، لذا يُستدعى متسلسلاً (سلسلة) من مثبّتكم. تتوفّر خيارات للتشغيل بلا مراقبة.²³

:: 画面表示・テキスト出力を一切出さずに導入する
WindowsAppRuntimeInstall.exe --quiet

:: 使用中のWindows App SDKプロセスを終了させたうえで強制更新する(1.1以降)
WindowsAppRuntimeInstall.exe --force

ثلاث نقاط ينبغي تثبيتها عند الإدخال.²³

• وجود امتيازات المدير يغيّر النتيجة. إذا شُغّل مرتفعاً وكان مستخدم التشغيل يملك امتيازات مدير، يُسجَّل للنظام كله (بما في ذلك المستخدمين الذين سيُضافون لاحقاً). وإلا صار الإدخال لمستخدم التشغيل فقط. قيمة العودة 0x80070005 هي بالضبط حالة «غير مرتفع / بلا امتيازات مدير».
• يُحكم بالنجاح أو الفشل من قيمة العودة. 0x0 نجاح، و0x80073d06 فشل إدخال حزمة واحدة أو أكثر. عند السلسلة من مثبّتكم انظروا هذه القيمة حتماً.
• زمن التشغيل الذي يُدخل في جهاز التطوير يُوافَق مع إصدار حزمة NuGet المشار إليها وقناة الإصدار.² ليس نادراً أن يكون سبب «يظهر في جهاز التطوير ولا يظهر لدى جهة التوزيع» هنا.

عند التوزيع معبّأ بـ MSIX يمكن معاملة توزيع زمن التشغيل كتبعية للحزمة، لكن يلزم بدل ذلك ذكر مفعّل COM في Package.appxmanifest (راجعوا نهاية 7.3).

7.3. الحد الأدنى للتنفيذ

using System;
using System.Windows.Forms;
using Microsoft.Windows.AppNotifications;
using Microsoft.Windows.AppNotifications.Builder;

internal static class ToastActivation
{
    private static readonly object Gate = new();
    private static Action? _pending;
    private static bool _uiReady;

    // 起動時に一度だけ。ハンドラー登録 → Register() の順序が重要
    public static void Initialize()
    {
        AppNotificationManager.Default.NotificationInvoked += (_, args) =>
        {
            // トーストのクリックやボタン押下がここに届く(引数はargs.Argumentsで判別)
            if (!args.Arguments.TryGetValue("action", out var action) || action != "openLog")
            {
                return;
            }

            // NotificationInvoked はバックグラウンドスレッドで発生する。
            // UIに触る処理は必ずUIスレッドへ渡すこと
            Dispatch(ShowLogWindow);
        };
        AppNotificationManager.Default.Register();
    }

    // MainForm の OnShown から呼ぶ。フォームができる前に届いた分をここで流す
    public static void MarkUiReady()
    {
        Action? pending;
        lock (Gate)
        {
            _uiReady = true;
            pending = _pending;
            _pending = null;
        }
        // OnShown は UI スレッドなので、そのまま実行してよい
        pending?.Invoke();
    }

    private static void Dispatch(Action action)
    {
        lock (Gate)
        {
            if (!_uiReady)
            {
                // トーストのクリックがアプリの起動そのものだった場合、ここへ来た
                // 時点ではまだフォームが1つも無い。預かっておいて MarkUiReady が流す
                _pending = action;
                return;
            }
        }
        MainWindow()?.Invoke(action);
        // WPFなら: Application.Current.Dispatcher.Invoke(action);
    }

    private static Form? MainWindow() =>
        Application.OpenForms.Count > 0 ? Application.OpenForms[0] : null;

    private static void ShowLogWindow() { /* ログウィンドウを開く */ }
}

// MainForm 側。起動のきっかけがトーストのクリックだった場合はここで拾う
protected override void OnShown(EventArgs e)
{
    base.OnShown(e);
    ToastActivation.MarkUiReady();
}

ToastActivation.Initialize();

// 通知を出す
var notification = new AppNotificationBuilder()
    .AddText("اكتمل استيراد الطلبات")
    .AddText("12 جديداً، خطأ واحد")
    .AddButton(new AppNotificationButton("فتح السجلّ")
        .AddArgument("action", "openLog"))
    .BuildNotification();
AppNotificationManager.Default.Show(notification);

الملاحظات العملية كما يلي.

• اشتركوا في NotificationInvoked قبل Register(). إن أخطأ الترتيب فات الحدث عندما يُشغَّل التطبيق بنقر Toast.¹²
• إذا كان النقر هو ما شغّل التطبيق نفسه، فلا يوجد نموذج واحد بعد عند عمل المعالج. كتابة «انظر Application.OpenForms وإن كان null فلا تفعل شيئاً» ترمي تشغيل هذا المسار صامتاً. كما أعلاه، احتفظوا به مرة ثم مرّروه بعد ظهور النموذج. حتى إن رُتّب الترتيب واستُقبل الحدث، الرمي هنا يصل إلى النتيجة نفسها.
• يقع NotificationInvoked على خيط خلفية. تنص العيّنة الرسمية أيضاً على «يقع على خيط خلفية، فمرّروا تحديثات واجهة المستخدم إلى خيط واجهة المستخدم». كتابة فتح نافذة أو لمس عناصر التحكّم مباشرة من المعالج تصادف استثناءات تتعلّق بالخيوط أو تجمّداً غير مفهوم. في WPF مرّروا إلى خيط واجهة المستخدم بـ Application.Current.Dispatcher.Invoke(...)، وفي WinForms بـ Control.Invoke(...).¹²
• قبل إنهاء التطبيق استدعوا AppNotificationManager.Default.Unregister(). تنص الوثائق الرسمية على وجوب تنظيف الموارد بـ Unregister قبل الإنهاء حتى يُشغَّل التطبيق بشكل صحيح عند نقر الإشعارات لاحقاً. أدرجوه إلى جانب NotifyIcon.Dispose() في معالجة قائمة «إنهاء» في الفصل 3 (عند إلغاء تثبيت تطبيق لن يستخدم وظيفة الإشعار بعد الآن مثلاً، تتوفّر على حدة UnregisterAll() التي تمحو معلومات التسجيل كلها).²⁴
• في التطبيق غير المُعبَّأ تتولّى Register() تلقائياً تسجيل خادم COM والمعالجة المكافئة لـ AUMID. وضع الاختصار وتسجيل السجل اللذان لزما في الجيل القديم (WinRT الخام) غير لازمين. عند التعبئة بـ MSIX يلزم بالعكس ذكر مفعّل COM في Package.appxmanifest.¹²
• يلزم الانتباه عند اختيار توزيع self-contained يضمّن زمن تشغيل Windows App SDK. تعتمد AppNotificationManager على حزمة Singleton في Windows App SDK، وتُرشد الوثائق رسمياً إلى اعتبارات عند الاستدعاء من تطبيق self-contained. تحقّقوا قبل تقرير طريقة التوزيع.²⁵
• الإشعار من عملية مرتفعة إلى مدير غير مدعوم. تفشل Show بهدوء بلا استثناء، فيصعب الانتباه إلى السبب. في التطبيقات التي تحتاج ارتفاعاً، ادرسوا فصلاً يترك الإشعار لعملية غير مرتفعة (تناولنا فكرة هذا الفصل في «طريقة كتابة عملية تفصل «المعالجة التي تحتاج امتيازات مدير فقط» في تطبيقات Windows»).¹³
• عندما يُنقر Toast، إن لم يكن التطبيق مشغَّلاً تُشغَّل عملية جديدة. في التطبيق المقيم في العلبة يلزم الجمع مع منع التشغيل المتعدد (راجعوا الفصل 3) وتصميم يمرّر المعالجة إلى المثيل القائم.

8. استخدام متقدّم ── Toast بشريط تقدّم وتنظيف الإشعارات

8.1. تحديث التقدّم داخل Toast ── UpdateAsync

تقدّم معالجة طويلة مثل «جارٍ استيراد 120 سجل طلب» لا يُعاد إخراج الإشعار مراراً، بل يُعاد كتابة شريط التقدّم داخل Toast واحد؛ هذا هو البناء الصحيح. في AppNotification توجد آلية ربط بيانات وتحديث لهذا الغرض.²⁶

البناء ثلاث مراحل. أولاً اجعلوا كل قيمة في شريط التقدّم عنصر نائب بطرق Bind، واعرضوا مع تعريف الإشعار بـ Tag (وGroup إن لزم). بعد ذلك يكفي تمرير AppNotificationProgressData إلى UpdateAsync فيُعاد كتابة محتوى Toast المعروض وحده.

const string tag = "import-progress";
const string group = "batch";

// 初回表示: 値はバインドにして、初期値をProgressに設定する
var notification = new AppNotificationBuilder()
    .AddText("جارٍ استيراد بيانات الطلبات")
    .AddProgressBar(new AppNotificationProgressBar()
        .BindStatus().BindValue().BindValueStringOverride())
    .SetTag(tag)
    .SetGroup(group)
    .BuildNotification();

notification.Progress = new AppNotificationProgressData(1) // シーケンス番号
{
    Status = "جارٍ الاستيراد...", Value = 0, ValueStringOverride = "0/120 سجلاً"
};
AppNotificationManager.Default.Show(notification);

// 進捗が進むたびに: シーケンス番号を増やして更新する
var data = new AppNotificationProgressData(2)
{
    Status = "جارٍ الاستيراد...", Value = 45 / 120.0, ValueStringOverride = "45/120 سجلاً"
};
await AppNotificationManager.Default.UpdateAsync(data, tag, group);

رقم التسلسل عدد صحيح غير صفري يبيّن ترتيب التحديث، وعند وصول عدة تحديثات متقدّمة ومتأخرة يُعرض الأكبر. آلية حتى لا يُرجع بقيمة قديمة حتى إن أُلقيت تحديثات على التوازي من معالجة غير متزامنة، لذا زيدوه رتيباً.²⁷

8.2. التمييز بين «التحديث» و«الاستبدال»

يمكن أيضاً تحديث المظهر بـ«استبدال» يعيد Show لإشعار جديد بنفس Tag، لكن السلوك يختلف.²⁶

توصية الوثائق الرسمية واضحة أيضاً: المسار الوسط تحديث، والاكتمال استبدال. لا حاجة لإعلام بمنبثقة في كل مرة صار التقدّم من 50% إلى 65%، أما «اكتمل الاستيراد (3 أخطاء)» فنريد أن يصل حتى إن كان المستخدم قد أغلق إشعار التقدّم. الشكل العملي الكلاسيكي عند الاكتمال استبدال بتخطيط آخر يُخرج شريط التقدّم ويضع زراً (مثل «عرض محتوى الخطأ»).

8.3. تنظيف الإشعارات القديمة المتبقية في مركز الإشعارات

تتراكم Toast في مركز الإشعارات حتى يحذفها المستخدم. إذا أخرج تطبيق مقيم عدة إشعارات يومياً، امتلأ مركز الإشعارات بإشعارات التطبيق القديمة وطُمر المهم.

إذا أُلحقت Tag / Group يمكن حذف إشعارات تطبيقكم من الكود (بتعيين وسم، أو مجموعة، أو الكل). يمكن أيضاً ضبط أجل صلاحية، لذا يُستحسن تقرير قواعد تنظيف مثل «سلسلة التقدّم تُحذف عند الاكتمال» و«سلسلة المعلومات أجلها قصير» مع تصميم إخراج الإشعار.²⁸

9. إدخال حالات «عدم وصول» الإشعار في التصميم

الإشعار المنبثق ليس وسيلة نقل مؤكدة. مسارات عدم العرض أو عدم الملاحظة موجودة كمسار سليم.

عدم الإزعاج يتحكّم فيه المستخدم أو سياسة المجموعة: في Windows 10 «وضع التركيز (Focus assist)»، وفي Windows 11 مفتاح «عدم الإزعاج» في «الإعدادات ← النظام ← الإشعارات». توجد حتى مواصفة تفعيله تلقائياً لمدة ساعة بعد ترقية نظام التشغيل.¹⁴ عمل وضع التركيز ليس «عدم إخراج إشعار» بل «كبت عرض اللافتة وإرساله إلى مركز الإشعارات»، لذا إن فتح المستخدم مركز الإشعارات لاحقاً رآه.¹⁵

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

في Windows 10 ما يعادل عدم الإزعاج هو «الإعدادات ← النظام ← وضع التركيز». التحقّق أولاً مما إذا وصل إلى مركز الإشعارات أقصر طريق للفصل: إن وصل فكبت لافتة في جانب نظام التشغيل (عدم الإزعاج ونحوه)، وإن لم يصل فاشكّوا في الإرسال نفسه من جانب التطبيق.

دلالة ذلك على التصميم بسيطة.

• استخدموا Toast قناة مساعدة «إن لُوحظ أمكنت الاستجابة أسرع»، واجعلوا المعلومات اللازمة للعمل قابلة للتأكيد حتماً في شاشة أو قائمة داخل التطبيق. لا تجعلوا «كان يفترض أن يظهر Toast» مقدّمة لتدفق العمل.
• للإشعارات التي لا بد من مقاطعتها (مثل تحذير إيقاف طارئ) توجد آلية تخترق عدم الإزعاج بإذن المستخدم عبر AppNotificationScenario.Urgent (إشعار مهم)²⁹، لكن الإسراف يجعل المستخدم يوقف إشعارات التطبيق كلها. ينبغي حصرها فيما هو طارئ فعلاً.

للحديث الأوسع عن كيفية عرض خلل جهاز خارجي ونحوه على الشاشة، راجعوا أيضاً «أفضل ممارسات تأكيد حالة الأجهزة الخارجية وعرضها».

10. عندما تريدون الإشعار من خدمة Windows

مطلب «عندما تكتشف خدمة مقيمة خللاً، نريد إعلام المستخدم المسجَّل دخوله بـ Toast» يظهر طبيعياً، لكن لا يمكن إخراج Toast مباشرة من الخدمة. منذ Windows Vista تعمل الخدمات في جلسة مخصّصة اسمها الجلسة 0، ولا تملك واجهة مستخدم للتفاعل مع المستخدم.³

النمط القياسي تكوين يفصل واجهة المستخدم إلى عملية في جانب جلسة المستخدم.

[セッション0]                      [ユーザーセッション]
 Windowsサービス   ←─ IPC ─→   トレイ常駐エージェント
 (監視・業務処理)   名前付きパイプ等   (NotifyIcon + AppNotification)

• تتفرّغ الخدمة للمراقبة ومعالجة العمل، وترسل الأحداث المراد الإشعار بها إلى الوكيل عبر IPC.
• الوكيل تطبيق مقيم في العلبة يُشغَّل عند تسجيل دخول المستخدم (الفصول 2 إلى 8 من هذا المقال نفسها)، ويعرض الحدث المستلم بـ Toast أو تغيّر الأيقونة.
• اختيار وسيلة IPC مرتَّب في «كيف نختار الاتصال بين عمليات Windows»، وطريقة بناء جانب الخدمة في «كيفية صنع خدمة Windows وتشغيلها»، وآلية الجلسة نفسها في «كيف نفهم فصل جلسات Windows ── Session 0 وRDP والتشغيل المتزامن لعدة مستخدمين».

في بيئة يسجّل فيها عدة مستخدمين الدخول معاً (RDP أو جهاز مشترك) سيعمل وكيل واحد لكل جلسة. إذا قرّرتم أولاً كمتطلّب «من ينبغي إشعاره» (الجميع أم مستخدم معيّن فقط) لم يمل التصميم.

11. الخلاصة

• أساس الإقامة في العلبة NotifyIcon. تُعرض بـ Icon + Visible = true، وحد Text 127 حرفاً (.NET 6+)، وفي مسار الإنهاء يُمرَّر Dispose() حتماً. تُستخدم الأيقونة والتلميح أيضاً عرضاً دائماً لـ«الحالة الحالية».
• «الإبقاء في العلبة حتى عند الإغلاق بـ ×» يُنفَّذ بإلغاء FormClosing، لكن يُلغى فقط عند CloseReason.UserClosing، ويُعدّ دائماً قائمة «إنهاء» صريحة.
• العرض الدائم للأيقونة لا يقرّره إلا المستخدم. اختفاء الأيقونة عند إعادة تشغيل Explorer يُعالَج بإعادة التسجيل عند TaskbarCreated (WinForms تلقائي).
• التنفيذ الجديد للإشعارات المنبثقة خيار واحد: AppNotificationManager في Windows App SDK. يعمل حتى من exe غير مُعبَّأ بلا معرّف حزمة، وRegister() تؤتمت التسجيل المُضني. إشعارات Community Toolkit مؤرشفة، وWinRT الخام صيانة فقط. للإشعار الخفيف الذي لا يحتاج زراً ولا سجلاً ولا تقدّماً، يبقى حكم الاكتفاء بـ ShowBalloonTip (الفصل 6).
• في التطبيق غير المُعبَّأ، إيصال زمن تشغيل Windows App SDK إلى جهة التوزيع مسؤولية جهة التوزيع. اكتبوا <WindowsPackageType>None</WindowsPackageType> في csproj، وأدرجوا سلسلة WindowsAppRuntimeInstall.exe من المثبّت في تصميم التوزيع (الفصل 7.2).
• مسار المعالجة الطويلة يُعاد كتابة شريط التقدّم في Toast واحد بهدوء عبر UpdateAsync، والاكتمال يُستبدل بمنبثقة؛ هذا النمط القياسي. أرفقوا Tag/Group وأدرجوا حذف الإشعارات القديمة في التصميم.
• Toast قناة مساعدة قد لا تصل بسبب عدم الإزعاج أو إيقاف الإشعارات. صمّموا المعلومات اللازمة بحيث يمكن تأكيدها داخل التطبيق، وانتبهوا إلى أن الإشعار من عملية مرتفعة غير مدعوم.
• الإشعار من الخدمة يُحقَّق بتكوين فصل: وكيل مقيم في العلبة في جانب جلسة المستخدم + IPC.

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

• منع التشغيل المتعدد لتطبيقات Windows ── Mutex مسمّى والتفعيل عند التشغيل المزدوج
• كيفية صنع خدمة Windows وتشغيلها ── من التمييز عن جدولة المهام حتى تحويل BackgroundService إلى خدمة
• كيف نختار الاتصال بين عمليات Windows ── جدول قرار الأنابيب المسمّاة / TCP / gRPC / الذاكرة المشتركة / COM
• كيف نفهم فصل جلسات Windows ── Session 0 وRDP والتشغيل المتزامن لعدة مستخدمين
• لماذا نستخدم .NET Generic Host وBackgroundService في تطبيقات سطح المكتب
• طريقة كتابة عملية تفصل «المعالجة التي تحتاج امتيازات مدير فقط» في تطبيقات Windows
• أفضل ممارسات تأكيد حالة الأجهزة الخارجية وعرضها - تصميم لا يكتفي بـ«متصل»

مجالات الاستشارة ذات الصلة

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

• تطوير تطبيقات Windows
• الاستشارة التقنية ومراجعة التصميم
• تواصل معنا

روابط مرجعية

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

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

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

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

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

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

كيف يمكنني إنشاء تطبيق مقيم في علبة النظام باستخدام WPF؟

لا يوجد في WPF عنصر تحكّم مكافئ لـ NotifyIcon، لذا فإن الحد الأدنى للإعداد هو تفعيل كل من UseWPF وUseWindowsForms في ملف csproj واستخدام NotifyIcon الخاص بـ WinForms. إذا أردتم أسلوب كتابة متوافقاً مع XAML، فإن مكتبة خارجية مثل H.NotifyIcon تُعد خياراً متاحاً، لكن ضعوا في الاعتبار أنها ليست مكوّناً رسمياً من Microsoft عند اتخاذ قرار اعتمادها.

ما هي واجهة برمجة التطبيقات التي ينبغي استخدامها للإشعارات المنبثقة؟

بالنسبة لأي تطوير جديد اعتباراً من عام 2026، سواء بنيتم تطبيق WinForms أو WPF أو تطبيقاً غير مُعبَّأ، فإن AppNotificationManager الخاص بـ Windows App SDK هو الخيار الموصى به رسمياً. أما Microsoft.Toolkit.Uwp.Notifications فقد أُرشفت ولم تعد جزءاً من Community Toolkit الحالية، في حين أن ToastNotificationManager الخاص بـ WinRT أصبح في وضع الصيانة فقط. إذا كان الكود الحالي لديكم يعمل بالفعل بأحد هذين الخيارين، فلا داعي للتسرّع في إعادة كتابته، لكن لا يوجد سبب لاختيارهما في عمل جديد.

ماذا يجب أن أتحقّق منه عندما لا يظهر الإشعار المنبثق؟

ابدأوا بإعدادات نظام التشغيل. إذا كانت ميزة «عدم الإزعاج» (Focus Assist) مفعّلة، فإن الإشعارات تتخطى شكل اللافتة وتذهب مباشرة إلى مركز الإشعارات، كما يمكن إيقاف الإشعارات لكل تطبيق على حدة أو على مستوى النظام بالكامل من تطبيق الإعدادات. على مستوى التنفيذ، السببان الشائعان هما أن AppNotification غير مدعومة عند إرسالها من عملية مرفوعة الصلاحيات (مسؤول)، وأن Windows.UI.Notifications الخام لا تعرض شيئاً عند استدعائها من تطبيق سطح مكتب بلا AUMID.

هل يمكن لخدمة Windows إرسال إشعارات منبثقة؟

لا، لا يمكنها ذلك. منذ Windows Vista تعمل الخدمات ضمن الجلسة رقم 0 (Session 0) ولا تملك القدرة على عرض واجهة مستخدم للتفاعل مع المستخدم. إذا احتجتم لإخطار المستخدم، فإن النمط القياسي هو وضع عملية وكيل مقيمة في علبة النظام ضمن جلسة المستخدم، وجعلها تتواصل مع الخدمة عبر آلية اتصال بين العمليات (IPC) مثل الأنابيب المسمّاة، على أن يتولّى الوكيل نفسه مسؤولية عرض الإشعار.

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

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

غو كومورا

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

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