Windowscommunitytoolkit: كيف يمكنني التعامل مع MasterDetail Back مع NavigationView BackButton؟

skendrot قد يكون قادرًا على المساعدة هنا

يبدو أن skendrot مشغول ، هل يمكن لشخص آخر إلقاء نظرة عليه؟ nmetulev ؟

مرحبًا ، كنت في إجازة ، شكرًا على اختبار الاتصال الإضافي. لا أعتقد أننا نتعامل مع هذا حاليًا ، لكنه شيء نتحدث عنه. لقد تحدثنا عن طريقة لإيقاف إظهار / إخفاء / استخدام زر رجوع النظام. لكن يمكنني أيضًا أن أرى أنه ربما يمكننا التكامل مع عرض التنقل الجديد أيضًا.
ما رأيك فيما يلي:

• افتراضي لاستخدام زر رجوع النظام. إذا كانت طريقة عرض التنقل الجديدة موجودة ، فاستخدمها بدلاً من ذلك
• لديك خيار لإيقاف تشغيل زر الرجوع تمامًا والسماح للمطور بتحديد كيفية التعامل مع ذلك

يمكننا أيضًا الحصول على تعداد للتحكم في زر الرجوع
النظام ، NavigationView ، إيقاف

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

ماذا عن الحصول على تعداد لهذا وكذلك إيقاف تشغيل زر رجوع النظام افتراضيًا ومن ثم يمكن للمطورين تشغيله إذا أرادوا ذلك؟ نظرًا لأنه يتم تشجيع التنقل عبر زر الرجوع الجديد داخل NavigationView في المستندات من الآن فصاعدًا.

IMO ، من شأنه أن يخلق تغييرًا في سلوك المستخدمين الحاليين ما لم نتمكن من اكتشاف طريقة عرض التنقل الجديدة. skendrot ، ما رأيك؟

نعم ، هذه نقطة عادلة ، كما أن إبقاء المستخدمين الحاليين تحت المراقبة مهم جدًا أيضًا ، أوافق.

جاء ذلك في التعليق الأول. احتفظ بالأشياء كما هي ، ولكن تحقق مما إذا كان لدينا NavigationView جديدة كأحد الوالدين المرئيين. إذا كان الأمر كذلك ، فيجب علينا فقط استخدام ذلك لزر الرجوع بدلاً من زر رجوع النظام. أعتقد أنه لا يزال يتعين علينا توفير طريقة لإيقاف تشغيله تمامًا إذا أراد المطور التحكم في كل شيء بنفسه

نعم ، خيارات skendrot مرنة دائمًا وجيدة دائمًا الحصول عليها بشكل خاص عند إجراء انتقال كبير. فكيف يجب أن يتقدم هذا الآن؟

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

1. استخدم زر الرجوع القياسي و "الإضاءة" إذا كان عرض التنقل الجديد في مكانه وقدم طريقة لإيقاف زر الرجوع تمامًا
2. قدم خيار تعداد جديد يسمح للمطور بالاختيار بين زر الرجوع القياسي وزر الرجوع لعرض التنقل وإيقاف تشغيله

صوّت 👍 مقابل 1 و 🎉 مقابل 2

سأجمع بين هذين الاثنين واستخدم التعداد للتحكم في كيفية إضاءة زر الرجوع من خلال توفير ثلاث قيم:

• تلقائي - افتراضي (يكتشف من تلقاء نفسه كيفية التعامل مع التنقل الخلفي)
• ميراث
• اطفء

أود أن أقترح ، بدلاً من Automatic و Legacy و Off ، أن تقدم خيارات تعداد واضحة فيما سيفعلونه. على سبيل المثال

الزر الخلفي السلوك:

• العرض
• UseExternal
• العودة معطل

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

يسمح لك UseExternal بتعيين التعليمات البرمجية ، أو عنصر تحكم زر الرجوع الذي تضعه بنفسك ، أو عنصر تحكم shell (في شريط العنوان للنوافذ القياسية ، أو في الشريط السفلي لنافذة المجموعات) أو من عنصر تحكم آخر. أعتقد أنه يمكنك جعل من الممكن توفير اسم عنصر تحكم في XAML والذي من شأنه تشغيل وتجاوز حدث الضغط على زر الرجوع لعنصر التحكم هذا.

سيعطل BackDisabled التنقل الخلفي تمامًا.

يمكن للمطورين والمشروعات مثل القالب 10 إنشاء صفحة أو صفحة نموذج مع وجود الإعدادات التي تسمح لهم بالتحكم في استخدام زر الرجوع.

أتفق معmdtauk!

mdtauk نعم بالتأكيد هذا الاقتراح أكثر منطقية ويبدو أكثر قوة.

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

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

هنا هو اقتراحي المحدث

Enum: BackButtonHandling

• تلقائي (افتراضي) - يستخدم الزر المضمن ما لم يكن NavigationView هو الأصل ، ثم استخدم التنقل الخلفي لـ NavigationView

• مضمن - استخدم الزر المضمن

• قديم - يجب التأكد من أننا ندعم زر الرجوع للخلف للمطورين الذين لم يبتعدوا عنه

• يدوي - دع المستخدم يرسم زر الرجوع الخاص به ويفعل ذلك كما يحلو له

بدلاً من Legacy ماذا عن System أو SystemAppViewBackButton أو AppView أو أي شيء آخر

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

أنا أحب النظام أكثر من القديم ، فهذا أفضل بكثير

لست مهتمًا بشكل خاص بالقيمة الافتراضية في كلتا الحالتين لأن الإصدار التالي هو تحديث رئيسي (5.0). أنا موافق على إبقائه افتراضيًا على النظام ثم تغيير الإعداد الافتراضي إلى تلقائي في 6.0.

ويمكن أن يكون هناك إشعار كتحذير بأن زر رجوع النظام سيتم إهماله في إصدار مستقبلي (6.0) شيء من هذا القبيل؟ أم أن زر رجوع النظام سيكون دائمًا خيارًا ، حتى بعد إصدار المجموعات (ربما في إصدار أبريل 2019)؟

ربما لن نتوقف عن زر "رجوع النظام" حتى يتم إهماله من النظام الأساسي.

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

حسنًا ، يجب أن أوضح: يجب علينا فقط إهمال الخيار من التعداد إذا كان سيتم إهماله أيضًا من النظام الأساسي (لا أعتقد أن هناك أي خطط للقيام بذلك)

لذلك يبدو أن هناك شريط أدوات كامل فقط لزر خلفي واحد (في حالة المجموعات)؟ أم أنه سيكون هناك المزيد من ضوابط النظام الأساسي عليه؟

لذلك يبدو أن هناك شريط أدوات كامل فقط لزر خلفي واحد (في حالة المجموعات)؟ أم أنه سيكون هناك المزيد من ضوابط النظام الأساسي عليه؟

لا أعرف أي ضوابط إضافية يمكن أن تضيفها الصدفة. ولكن نظرًا لأن هذا ليس حلاً أنيقًا للتنقل الخلفي - فإن التوجيه هو التعامل معه في التطبيق.

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

نعم ، يبدو فقط الكثير من مساحة واجهة المستخدم المهدرة هناك ، زر واحد فقط هناك.

touseefbsb اعتبارًا من الآن ، هذا هو السلوك القياسي إذا اخترت السماح لـ Shell بمعالجة الزر الخلفي مع نافذة مجموعات. نظرًا لأن المجموعات لا تزال غير مضمنة في إصدارات Windows ، فقد يتغير هذا ، ولكن من الأفضل تمكين غلاف التحكم / التطبيق للتعامل مع رسم زر الرجوع ، والابتعاد عن التعامل مع شريط العنوان.

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

قد لا تصل المجموعات إلى إصدار 19H1 ، لذلك في الوقت الحالي ، من المهم أن تبدو التطبيقات جيدة وأن تمتد إلى أشرطة العنوان عندما يكون ذلك ممكنًا. يمكن للمطورين أيضًا اختيار عدم السماح لتطبيقهم بالعمل مع المجموعات ، لذا فإن التمتع بالمرونة مع عنصر التحكم ، وتغيير / تجاوز الإعداد الافتراضي عند التشغيل في علامة تبويب المجموعات ، أمر منطقي. على الأقل بالنسبة لي لول

mdtauk إذا تطبيقهم لن يتم فتحه في مجموعات؟

touseefbsb هكذا أفهمها. عند فتحه من علامة تبويب أخرى ، سيظهر في نافذته الخاصة ، ولن يكون من الممكن تخزينه مع علامات تبويب أخرى أيضًا.

مضاعفات صغيرة لدعم NavigationView الجديدة. لا يحتوي معالج الحدث BackRequested على طريقة لإلغاء الحدث أو وضع علامة على أنه تم التعامل معه. بدون هذه القدرة ، سيتعامل MasterDetailsView مع الانتقال من طرق العرض "التفاصيل" إلى "العرض الرئيسي" ومن ثم سيتعامل المطور مع العودة إلى الحالة مرة أخرى أيضًا.
يمكننا دعم IFF ، يتم استخدام إطار أيضًا للمساعدة في التنقل.

mvegaca ، هل تستخدم إطارًا لاستضافة عنصر التحكم؟ ماذا لو حاولنا بدلاً من ذلك التعامل مع NavView مرة أخرى ، فقمنا بالتعامل مع الإطار (الذي يجب أن يتعامل مع السيناريوهات خارج NavView أيضًا)؟

نحن نتعامل بالفعل مع التنقل داخل الإطار بحيث يكون مدمجًا بالفعل. لا يمكننا الاعتماد على استخدام NavigationView الجديد ما لم يكن هناك إطار أيضًا

لذا ، إذا كانت WTS تستخدم إطارًا للتنقل داخل NavView ، فهل يجب أن تعمل بالفعل؟

نعم ، مع إضافات غير مرغوب فيها. سيعمل MasterDetailsView على تمكين زر رجوع النظام ، والذي لا تريده WTS. ولكن ، إذا تعاملوا مع زر الرجوع إلى NavigationView من خلال التنقل في إطار ، فسيقوم MasterDetailsView بالتقاط هذا الحدث ، وإذا كانت حالة التفاصيل المطوية ، فسيتم وضع علامة عليه كإلغاء والعودة إلى العرض الرئيسي.

نحن (WTS) نستخدم إطارًا داخل NavView. يعمل الزر الخلفي لـ navview بالفعل ، ولكن يظهر زر رجوع إضافي للنظام. للتعامل مع التنقل الخلفي ، نقوم بتطبيق Frame.GoBack ، لكن مشكلتنا هي زر رجوع النظام الذي يظهر قبل العودة. لذلك ، لست متأكدًا مما إذا كنا بخير. هل هناك طريقة لاختبار هذا؟

نعم ، هذه هي المشكلة التي يتم إصلاحها في العلاقات العامة الخاصة بـ

مرحبًا nmetulev ، أحاول اختبار خاصية BackButtonBehaviorProperty الجديدة في نسخة من مستودع git لـ skendrot ولكن لا يمكنني تجميع استهداف التطبيق مباشرة إلى المكتبة.
هل يمكنك الموافقة على العلاقات العامة لاختبار هذه التغييرات في حزم MyGet CI؟

شكرا

mvegaca واجهت نفس المشكلة عند محاولة الاختبار. لم أتمكن من الرجوع إلى نسختى المحلية من التجميعات. نحتاج إلى معرفة ما يجري هنا لأنه يجعل اختبار المشكلات أكثر صعوبة

ما هي المشاكل التي تواجهها مع اختبار التجميعات؟

لقد أضفنا تطبيق PoC في حل WCT ، وقم بإزالة مرجع حزمة nuget والإشارة مباشرة إلى المشاريع.
عندما أقوم بتجميع المشروع ، حصلت على الخطأ التالي في جميع ملفات XAML:

xml C:\dev\skendrot\UWPCommunityToolkit\Issue2475PoC\Issue2475PoC.csproj : XamlCompiler error WMC1013: XAML files 'App.xaml' and 'App.xaml' have the same project path 'App.xaml'. Each file must have a unique project path.

يحدث هذا أيضًا إذا أضفت تطبيق UWP App1 جديدًا فارغًا إلى الحل.
xml XAML files 'App.xaml' and 'App.xaml' have the same project path 'App.xaml'. Each file must have a unique project path. App1 C:\dev\skendrot\UWPCommunityToolkit\App1\App1.csproj

شكرا nmetulev ؛)

أوصي ببناء الكتل محليا والرجوع إليها. يمكنك القيام بذلك باستخدام البرنامج النصي build\build.ps1 والذي يجب أن يولد القطع الصغيرة في مجلد bin.

mvegaca نفس المشكلات التي كنت أراها

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

لقد اختبرناها محليًا وهي تعمل بشكل جيد
يمكنك دمج العلاقات العامة إذا كان كل شيء على ما يرام بالنسبة لك.

شكرا لكم جميعا يا رفاق

تم دمج العلاقات العامة

مرحبا nmetulev

لقد حاولت استخدامه في الإصدار التجريبي 5.0.0-preview.gb86cb1c4cb ولكن الخاصية BackButtonBehavior غير متاحة.

متى تعتقد أن هذا الإصلاح سيكون متاحًا في الإصدار التجريبي وسيكون متاحًا في الإصدار الثابت؟

شكرا

نعم ، سيكون متاحًا في الإصدار 5.0.0 الأسبوع المقبل. يتوفر أيضًا في الإصدار المسبق على MyGet: https://dotnet.myget.org/gallery/uwpcommunitytoolkit