Windowscommunitytoolkit: मैं नेविगेशन व्यू बैकबटन के साथ मास्टरडिटेल बैक को कैसे संभाल सकता हूं?

@skendrot यहाँ मदद करने में सक्षम हो सकता है

लगता है @skendrot व्यस्त है, क्या कोई और इसे देख सकता है? @nmetulev ?

अरे, छुट्टी पर था, अतिरिक्त पिंग के लिए धन्यवाद। मुझे नहीं लगता कि हम वर्तमान में इसे संभाल रहे हैं, लेकिन यह कुछ ऐसा है जिसके बारे में हम बात कर रहे हैं। हमने सिस्टम बैक बटन को दिखाना/छिपाना/उपयोग करना बंद करने के तरीके के बारे में बात की थी। लेकिन मैं यह भी देख सकता था कि शायद हम नए नेविगेशन दृश्य के साथ भी एकीकृत हो सकें।
आप निम्नलिखित के बारे में क्या सोचते हैं:

• सिस्टम बैक बटन का उपयोग करने के लिए डिफ़ॉल्ट। यदि नया नेविगेशन दृश्य मौजूद है, तो इसके बजाय इसका उपयोग करें
• बैक बटन को पूरी तरह से बंद करने का विकल्प है और डेवलपर को यह तय करने की अनुमति दें कि इसे कैसे संभाला जाना चाहिए

बैक बटन को नियंत्रित करने के लिए हमारे पास एक एनम भी हो सकता है
सिस्टम, नेविगेशन व्यू, ऑफ

मुझे व्यवहार को नियंत्रित करने के लिए एनम होना पसंद है, जो इसे संभालने के लिए सबसे अधिक डेवलपर के अनुकूल तरीका लगता है। इसे पूरी तरह से बंद करने और डेवलपर को वापस नेविगेशन को संभालने का तरीका होने से भविष्य के परिदृश्यों के लिए भी समझ में आता है कि हम तुरंत समर्थन नहीं कर सकते हैं

इसके लिए एक एनम होने और डिफ़ॉल्ट रूप से सिस्टम बैक बटन को बंद करने के बारे में और फिर डेवलपर्स इसे चालू कर सकते हैं यदि वे चाहते हैं? क्योंकि नेविगेशन व्यू के भीतर नए बैक बटन नेविगेशन को आगे बढ़ने वाले डॉक्स में प्रोत्साहित किया जा रहा है।

IMO, जो मौजूदा उपयोगकर्ताओं के लिए एक व्यवहार परिवर्तन पैदा करेगा जब तक कि हम नए नेविगेशन दृश्य का पता नहीं लगा सकते। @skendrot , आपको क्या लगता है?

हाँ, यह एक उचित बिंदु है, मौजूदा उपयोगकर्ताओं को नियंत्रण में रखना भी बहुत महत्वपूर्ण है, मैं सहमत हूँ।

पहली टिप्पणी में इसका उल्लेख किया गया था। चीजों को वैसे ही रखें जैसे वे हैं, लेकिन देखें कि क्या हमारे पास विज़ुअल पैरेंट के रूप में एक नया नेविगेशन व्यू है। यदि ऐसा है, तो हमें सिस्टम बैक बटन के बजाय बैक बटन के लिए इसका उपयोग करना चाहिए। मुझे लगता है कि हमें अभी भी इसे पूरी तरह से बंद करने का एक तरीका प्रदान करना चाहिए यदि कोई डेवलपर स्वयं सब कुछ नियंत्रित करना चाहता है

हां @skendrot विकल्प हमेशा लचीले होते हैं और एक बड़ा संक्रमण करते समय विशेष रूप से हमेशा अच्छा होता है। तो यह अब कैसे आगे बढ़ना चाहिए?

जो भी विकल्प तय किया जाएगा, मैं उस पर नियंत्रण कर लूंगा। हमें तय करना है, क्या हम जा रहे हैं

1. यदि नया नेविगेशन दृश्य मौजूद है तो मानक बैक बटन और "लाइट-अप" का उपयोग करें और बैक बटन को पूरी तरह से बंद करने का एक तरीका प्रदान करें
2. एक नया एनम विकल्प प्रदान करें जो डेवलपर को मानक बैक बटन, नेविगेशन व्यू बैक बटन और ऑफ के बीच चयन करने की अनुमति देता है

को 1 और को 2 . को वोट दें

मैं इन दोनों को जोड़ूंगा और एनम का उपयोग यह नियंत्रित करने के लिए करूंगा कि बैक बटन तीन मान प्रदान करके कैसे रोशनी करता है:

• स्वचालित - डिफ़ॉल्ट (यह अपने आप पता चलता है कि वापस नेविगेशन को कैसे संभालना है)
• विरासत
• बंद

मैं सुझाव दूंगा कि स्वचालित, विरासत और बंद के बजाय, आप एनम विकल्प प्रदान करते हैं जो स्पष्ट हैं कि वे क्या करेंगे। उदाहरण के लिए

बैकबटन व्यवहार:

• डिस्प्लेइनलाइन
• बाहरी का प्रयोग करें
• पीछे अक्षम

नियंत्रण के भीतर एक मानक स्टाइल बैक बटन प्रदर्शित करने के मार्गदर्शन के बाद, डिस्प्लेइनलाइन डिफ़ॉल्ट होगी। यह गेमपैड पर बी बटन या कीबोर्ड पर बैकस्पेस कुंजी के साथ भी काम कर सकता है जब नियंत्रण पर ध्यान केंद्रित हो।

UseExternal आपको कोड में सेट करने की अनुमति देगा, एक बैक बटन नियंत्रण जिसे आप स्वयं रखते हैं, शेल नियंत्रण (मानक विंडो के लिए टाइटल बार में, या सेट विंडो के लिए निचले बार में) या किसी अन्य नियंत्रण से। मुझे लगता है कि आप एक्सएएमएल में एक नियंत्रण नाम प्रदान करना संभव बना सकते हैं जो उस नियंत्रण के लिए बैक बटन दबाए गए ईवेंट को ट्रिगर और ओवरराइड करेगा।

BackDisabled बैक नेविगेशन को पूरी तरह से अक्षम कर देगा।

टेम्प्लेट 10 जैसे देव और प्रोजेक्ट, सेटिंग्स के साथ एक पेज या टेम्प्लेट पेज बना सकते हैं जो उन्हें बैक बटन के उपयोग को नियंत्रित करने की अनुमति देता है।

@mdtauk से सहमत हैं!

@mdtauk हाँ निश्चित रूप से यह सुझाव अधिक समझ में आता है और अधिक शक्तिशाली लगता है।

मैं नियंत्रण के अंदर एक बैक बटन बनाने के साथ पूरी तरह से ठीक हूं, जो वर्तमान बैक बटन मार्गदर्शन से मेल खाता है।

हालाँकि, हमें नेविगेशन व्यू बैक बटन के लिए भी स्वचालित हैंडलिंग प्रदान करनी चाहिए। मुझे नहीं लगता कि बैक नेविगेशन को भी अक्षम करना समझ में आता है, यह कुछ ऐसा होना चाहिए जिसे उपयोगकर्ता को संभालना चाहिए

यहाँ मेरा अद्यतन सुझाव है

Enum: बैकबटन हैंडलिंग

• स्वचालित (डिफ़ॉल्ट) - इनलाइन बटन का उपयोग तब तक करता है जब तक कि नेविगेशन व्यू पैरेंट न हो, और फिर नेविगेशन व्यू बैक नेविगेशन का उपयोग करें

• इनलाइन - इनलाइन बटन का उपयोग करें

• विरासत - यह सुनिश्चित करने की आवश्यकता है कि हम उन डेवलपर्स के लिए शेल बैक बटन का समर्थन करते हैं जो इससे दूर नहीं गए हैं

• मैनुअल - उपयोगकर्ता को अपना बैक बटन खींचने दें और जैसा चाहें वैसा करें

Legacy बजाय System या SystemAppViewBackButton या AppView या कुछ और के बारे में कैसे

साथ ही, पिछड़ी संगतता बनाए रखने के लिए, और कोई ब्रेकिंग परिवर्तन नहीं है, डिफ़ॉल्ट रूप से विरासत विकल्प नहीं होना चाहिए। फिर अगले प्रमुख संस्करण में हम डिफ़ॉल्ट को ऑटो में बदल सकते हैं

मुझे विरासत से बेहतर सिस्टम पसंद है, यह बहुत बेहतर है

मैं किसी भी तरह से डिफ़ॉल्ट मान के बारे में विशेष रूप से पेटीनेट नहीं हूं क्योंकि अगला संस्करण एक प्रमुख अपडेट (5.0) है। मैं इसे सिस्टम में डिफ़ॉल्ट रखने और फिर 6.0 में डिफ़ॉल्ट को स्वचालित में बदलने के साथ ठीक हूं।

और एक चेतावनी के रूप में एक नोटिस हो सकता है कि सिस्टम बैक बटन को भविष्य में रिलीज ( 6.0 ) में कुछ इस तरह से हटा दिया जाएगा? या सिस्टम बैक बटन हमेशा एक विकल्प होगा, सेट जारी होने के बाद भी (शायद अप्रैल 2019 रिलीज में)?

हम शायद सिस्टम बैक बटन को तब तक पदावनत नहीं करेंगे जब तक कि इसे प्लेटफॉर्म से हटा नहीं दिया जाता।

सेट के साथ भी, सिस्टम बैक बटन को हटा नहीं दिया जा रहा है। यह इसे टैब के नीचे एक बार में बैक बटन के साथ रखेगा। लेकिन अगर सेट है, तो आपको बिल्कुल इन ऐप बटन पर स्विच करना चाहिए

ठीक है, मुझे स्पष्ट करना चाहिए: हमें केवल एनम से विकल्प को हटा देना चाहिए यदि इसे मंच से भी हटा दिया जाएगा (मुझे विश्वास नहीं है कि ऐसा करने की कोई योजना है)

तो स्पष्ट रूप से केवल 1 बैकबटन (सेट के मामले में) के लिए एक संपूर्ण टूलबार है? या उस पर और प्लेटफ़ॉर्म नियंत्रण होंगे?

तो स्पष्ट रूप से केवल 1 बैकबटन (सेट के मामले में) के लिए एक संपूर्ण टूलबार है? या उस पर और प्लेटफ़ॉर्म नियंत्रण होंगे?

मैं किसी भी अतिरिक्त नियंत्रण के बारे में नहीं जानता जो खोल जोड़ देगा। लेकिन ऐसा इसलिए है क्योंकि यह बैक नेविगेशन के लिए सुरुचिपूर्ण समाधान से बहुत दूर है - कि मार्गदर्शन इसे ऐप में संभालना है।

यदि आप इसके बारे में सोचते हैं, तो बैक बटन को सेट टैब के भीतर स्कोप किया जाता है। यह टैब के साथ दिखाई नहीं देगा, और इसलिए टाइटलबार में दिखाई नहीं दे सकता है।

हाँ, यह वहाँ बहुत अधिक व्यर्थ UI स्थान दिखता है, वहाँ केवल 1 बटन है।

@touseefbsb अभी के रूप में, मानक व्यवहार यही होगा यदि आप शैल को सेट विंडो के साथ बैक बटन को संभालने देना चुनते हैं। चूंकि सेट अभी भी विंडोज़ बिल्ड में शामिल नहीं है, यह बदल सकता है, लेकिन बैक बटन को खींचने के लिए नियंत्रण/ऐप खोल को सक्षम करने के लिए बेहतर है, और टाइटलबार को इसे संभालने से दूर ले जाएं।

मैं सहमत हूं, यही कारण है कि मुझे लगता है कि टाइटलबार सामग्री से दूर जाना और ऐप को टाइटल बार में विस्तारित करना भी ऐप को सेट के साथ ठीक से उपयोग करने में मदद करेगा।

सेट इसे 19H1 रिलीज़ के लिए भी नहीं बना सकते हैं, इसलिए कुछ समय के लिए, ऐप्स का अच्छा दिखना और जब संभव हो तो टाइटलबार में विस्तार करना महत्वपूर्ण है। देव अपने ऐप को सेट के साथ काम करने की अनुमति नहीं देने का विकल्प भी चुन सकते हैं, इसलिए नियंत्रण के साथ लचीलापन होना, और सेट टैब में चलते समय डिफ़ॉल्ट को बदलना/ओवरराइड करना समझ में आता है। कम से कम यह मेरे लिए करता है lol

@mdtauk अगर

@touseefbsb इस तरह मैं इसे समझता हूं। जब किसी अन्य टैब से खोला जाता है तो यह अपनी विंडो में दिखाई देगा, अन्य टैब के साथ भी संग्रहीत नहीं किया जा सकेगा।

नए नेविगेशन व्यू का समर्थन करने के लिए छोटी जटिलता। BackRequested ईवेंट हैंडलर में ईवेंट को रद्द करने या यह चिह्नित करने का कोई तरीका नहीं है कि इसे हैंडल किया गया है। इस क्षमता के बिना MasterDetailsView विवरण से मास्टर दृश्यों तक जाने को संभाल लेगा और फिर डेवलपर राज्य में वापस जाने का भी काम संभाल लेगा।
हम आईएफएफ का समर्थन कर सकते हैं एक फ्रेम का उपयोग नेविगेशन की सहायता के लिए भी किया जा रहा है।

@mvegaca , क्या आप नियंत्रण होस्ट करने के लिए फ्रेम का उपयोग करते हैं? क्या होगा यदि इसके बजाय NavView पर वापस संभालने का प्रयास करते हुए, हम एक फ़्रेम पर वापस हैंडल करते हैं (जो कि NavView के बाहर के परिदृश्यों को भी संभालना चाहिए)?

हम पहले से ही फ्रेम नेविगेशन को संभालते हैं ताकि यह पहले से ही अंतर्निहित हो। हम नए नेविगेशन व्यू का उपयोग करने पर भरोसा नहीं कर सकते जब तक कि कोई फ्रेम भी न हो

तो अगर डब्ल्यूटीएस नेवव्यू के अंदर अपने नेविगेशन के लिए फ्रेम का उपयोग कर रहा है, तो इसे पहले से ही काम करना चाहिए?

हाँ, अवांछित अतिरिक्त के साथ। MasterDetailsView सिस्टम बैक बटन को सक्षम करेगा, जो WTS नहीं चाहता। लेकिन, अगर वे एक फ्रेम में नेविगेट करके नेविगेशन व्यू बैक बटन को संभालते हैं, तो मास्टरडिटेल्स व्यू उस घटना को पकड़ लेगा, और यदि यह संक्षिप्त विवरण स्थिति है, तो इसे रद्द के रूप में चिह्नित करेगा और मास्टर व्यू पर वापस चला जाएगा।

हम (WTS) NavView के अंदर एक फ्रेम का उपयोग कर रहे हैं। नैविव्यू बैकबटन पहले से ही काम कर रहा है, लेकिन एक अतिरिक्त सिस्टम बैक बटन दिखा रहा है। बैक नेविगेशन को संभालने के लिए हम Frame.GoBack करते हैं, लेकिन हमारी समस्या सिस्टम बैक बटन है जो वापस जाने से पहले दिखाया जाता है। इसलिए, मुझे यकीन नहीं है कि हम ठीक हैं। क्या इसका परीक्षण करने का कोई तरीका है?

हाँ, यही समस्या है @skendrot का PR ठीक कर रहा है (#2561)। यह आश्चर्यजनक होगा यदि आप इसका परीक्षण भी कर सकते हैं।

हाय मैं @skendrot की एक Git भंडार क्लोन में नए BackButtonBehaviorProperty परीक्षण करने के लिए कोशिश कर रहा हूँ, लेकिन मैं @nmetulev एप्लिकेशन पुस्तकालय में लक्ष्यीकरण सीधे संकलन नहीं कर सकते।
क्या आप MyGet CI पैकेज में इस परिवर्तन का परीक्षण करने के लिए PR को स्वीकृति दे सकते हैं?

धन्यवाद

@mvegaca मुझे परीक्षण करने की कोशिश करते समय भी यही समस्या थी। मैं विधानसभाओं की अपनी स्थानीय प्रति का संदर्भ नहीं दे सका। हमें यह पता लगाने की जरूरत है कि यहां क्या हो रहा है क्योंकि यह परीक्षण के मुद्दों को और अधिक कठिन बना देता है

असेंबली के परीक्षण के साथ आपको क्या समस्याएं आ रही हैं?

हमने डब्ल्यूसीटी समाधान में एक पीओसी ऐप जोड़ा है, नगेट पैकेज संदर्भ और परियोजनाओं के लिए सीधे संदर्भ हटा दें।
जब मैं प्रोजेक्ट संकलित करता हूं तो मुझे सभी एक्सएएमएल फाइलों में निम्न त्रुटि मिली:

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 स्क्रिप्ट का उपयोग करके कर सकते हैं जो बिन फ़ोल्डर में नग उत्पन्न करना चाहिए।

@mvegaca वही मुद्दे जो मैं देख रहा था

दुर्भाग्य से परियोजनाओं को सीधे संदर्भित नहीं किया जा सकता क्योंकि वे समाधान विन्यास पर निर्भर करते हैं। विकास के लिए, मैं स्रोत फ़ाइलों को सीधे नई परियोजना में जोड़ता हूं क्योंकि यह नमूना ऐप में विकसित होने वाले बेहतर और तेज़ काम करता है। परीक्षण के लिए, मैं हमेशा स्थानीय रूप से नगेट्स का निर्माण करता हूं और उनका संदर्भ देता हूं

हमने इसे स्थानीय रूप से परीक्षण किया है और यह ठीक काम करता है
आप पीआर को मर्ज कर सकते हैं यदि यह आपके लिए ठीक है।

आप सभी लोगों का धन्यवाद

PR merged

नमस्ते @nmetulev

मैंने इसे पूर्व-रिलीज़ संस्करण 5.0.0-preview.gb86cb1c4cb में उपयोग करने का प्रयास किया है लेकिन संपत्ति BackButtonBehavior उपलब्ध नहीं है।

आपको कब लगता है कि यह फ़िक्स रिलीज़-पूर्व संस्करण पर उपलब्ध होगा और स्थिर संस्करण पर उपलब्ध होगा?

धन्यवाद

हाँ, यह अगले सप्ताह 5.0.0 रिलीज़ में उपलब्ध होगा। यह MyGet पर प्री-रिलीज़ पर भी उपलब्ध है: https://dotnet.myget.org/gallery/uwpcommunitytoolkit