WPF लेआउट: माप और व्यवस्था

एमएसडीएन ( 1 , 2 ) से डब्ल्यूपीएफ लेआउट सिस्टम क्या हो सकता है, इसका एक सामान्य विचार। यह कहता है कि नियंत्रण एक दृश्य वृक्ष बनाते हैं, प्रत्येक नियंत्रण की अपनी विशिष्ट आयत होती है, जिसके भीतर यह खींचा जाता है, कि इन आयतों की परिभाषा लेआउट सिस्टम को सौंपी गई है और इसे 2 चरणों (माप और व्यवस्था) में रखा गया है और WPF है साधारण तत्काल के विपरीत मोड ग्राफिक सिस्टम को बनाए रखा गया है और इस दृष्टिकोण के क्या फायदे हैं।

हालांकि, जब एमएसडीएन को पढ़ते हैं, तो कई सवाल उठते हैं, जिनका प्रलेखन में जवाब नहीं दिया जाता है, और आप केवल अनुमान लगा सकते हैं कि क्या हो रहा है। उदाहरण के लिए, क्या होता है अगर माप चरण में एक बच्चा नियंत्रण अपने लिए एक आकार का अनुरोध करता है जो उपलब्ध से अधिक हो जाता है जो इसे पारित कर दिया गया है? या - कैसे, यदि आवश्यक हो, तो मेजरऑवराइड और अरेंजऑवराइड विधियों को सही तरीके से लागू करने के लिए ताकि लिखित कोड माप और व्यवस्था के चरणों को कैसे किया जाए, इस पर स्वीकार किए गए सम्मेलनों का विरोध नहीं करता है? क्या माप चरण में प्राप्त परिणाम अरेंज स्टेज और रेंडरिंग को प्रभावित करता है, या क्या अरेंज कॉल केवल रेंडरिंग को प्रभावित करता है, और माप एक विशुद्ध रूप से सूचनात्मक चरण है?

आइए अधिक विस्तार से समझने की कोशिश करें कि पर्दे के पीछे क्या हो रहा है।

रिटायर्ड मोड सिस्टम

सबसे पहले, आइए याद रखें कि कौन सी बरकरार मोड ग्राफिक प्रणाली है , जो डब्ल्यूपीएफ है। यह ड्रॉइंग ग्राफिक्स के लिए सिर्फ एक दृष्टिकोण है, जिसमें रिड्राइविंग की आवश्यकता वाले क्षेत्रों की पहचान करने और इस रिडरिंग को निष्पादित करने की जिम्मेदारी ग्राफिक्स सिस्टम में स्थानांतरित हो जाती है। यही है, यह WPF है जो यह सुनिश्चित करने के लिए ज़िम्मेदार है कि यदि आवश्यक हो तो हर खिड़की और नियंत्रण फिर से तैयार किया जाता है। प्रोग्रामर अब WM_PAINT जैसी घटनाओं से निपटने के बारे में चिंतित नहीं है, जैसा कि Win32 API और WindowsForms के साथ हुआ था, लेकिन नियंत्रण के लिए आवश्यक होने पर बस रेंडरिंग विधि सेट करता है, और WPF यह निर्धारित करेगा कि कब और किस टुकड़े को पुन: अमान्य किया जाना है। प्रोग्रामेटिक रूप से, यह इस तरह दिखता है: उन क्षेत्रों को परिभाषित करने के बजाय जिन्हें फिर से तैयार करने और WM_PAINT संदेश आने पर हर बार इस प्रक्रिया को करने की आवश्यकता होती है , प्रोग्रामर एक बार नियंत्रण आकर्षित करने के लिए आवश्यक आदेशों के अनुक्रम को इंगित करता है। यह ऑनरेंडर विधि में किया जाता है। ऑनरेंडर विधि को WPF प्रणाली द्वारा कहा जाता है:

• यदि आप अभी भी नहीं जानते कि यह नियंत्रण कैसे बनाया जाए
• अगर कुछ डिपेंडेंसीप्रोपरेटी फ्लैग के साथ बदल गई है। फ्रेमप्रोपरेटीमेटेटाओएशन। एफ़ेक्ट्स रेंडर (उदाहरण के लिए, बटन.कंटेंट ) या अन्य झंडे के साथ जो स्पष्ट रूप से लीडरशिप को प्रभावित करता है
• यदि नियंत्रण को स्पष्ट रूप से अमान्य के लिए चिह्नित किया गया है ( InvalidateMeasure , InvalidateArrange या InvalidateVisual को कॉल करके)

OnRender विधि को DrawingContext तर्क के साथ कहा जाता है, जिसमें हम DrawEllipse प्रकार , आदि के कथित ड्राइंग तरीकों को खींचते हैं । कथित तौर पर, क्योंकि वास्तव में प्रतिपादन नहीं होता है, और हमारे सभी कॉल कमांड कतार में जोड़े जाते हैं, और इसका उपयोग तब किया जाएगा जब WPF निर्णय लेता है कि नियंत्रण को फिर से व्यवस्थित करने की आवश्यकता है।

दरअसल, यहां एक सामान्य प्रश्न का उत्तर निहित है - मान लीजिए कि हमारे पास एक बटन है जिस पर कुछ लिखा है, हम इस बटन के पाठ को बदलते हैं - लेकिन किस बिंदु पर और यह कैसे निर्धारित करता है कि आपको स्वयं को बदलने और इसे फिर से तैयार करने की आवश्यकता है? आखिरकार, हमने संपत्ति का मूल्य बदल दिया। और निम्न होता है: बटन पाठ रेंडरिंग को प्रभावित करता है, और संबंधित ध्वज के साथ चिह्नित किया जाता है, इसलिए इस संपत्ति के मूल्य को बदलने से बटन को गंदे के रूप में चिह्नित किया जाता है, अर्थात, जिसे फिर से तैयार करने की आवश्यकता होती है। और इसके तुरंत बाद, WPF इसके लिए एक रेंडरिंग अपडेट करेगा। यह तुरंत नहीं होगा, लेकिन केवल तब जब WPF के पास इसके लिए समय हो। यही है, यदि प्रतिस्थापन के तुरंत बाद आपको रेंडरसाइज़ मिलता है, तो यह नहीं बदलेगा। लेकिन अगर आप मार्कअप को अपडेटलेयूट () विधि का उपयोग करके अद्यतन करने के लिए मजबूर करते हैं, तो रेंडरसाइज़ वह हो जाएगा जो बदले हुए पाठ से मेल खाती है। दरअसल, इस तंत्र के साथ, वैसे, डिस्पैचर । इनवोक प्राथमिकता भी जुड़ी हुई है - उपलब्ध प्राथमिकताओं में प्राथमिकता प्राथमिकता है। इसका मतलब है कि जब इस प्राथमिकता वाले एक प्रतिनिधि को बुलाया जाता है, तो उसे तत्वों को प्रस्तुत करने के लिए निष्पादित प्रक्रियाओं के साथ निष्पादित किया जाएगा।

मापने

यह इतना महत्वपूर्ण क्यों है? क्योंकि कदम माप और व्यवस्था , जिसके भीतर तत्वों की स्थिति होती है, एक समान तरीके से काम करते हैं। उन्हें एक बार कॉल किया जाता है, और मापीएसविले और अरेंजआईवी अमान्य झंडे नियंत्रण के लिए निर्धारित किए जाते हैं। इसके बाद, कुछ भी नहीं करते हुए, माप और व्यवस्था को तुरंत नियंत्रण वापस करने के लिए कॉल। इन चीजों को पुनः प्राप्त करने के लिए नियंत्रण को मजबूर करने के लिए, किसी को फिर से कुछ DependencyProperty को AffectsMeasure / AffectsArrange फ्लैग के साथ बदलना होगा, या इनवैलिडमैरेंस / InvalidateArange को कॉल करके झंडे को रीसेट करना होगा। प्रलेखन यह भी कहता है कि माप का पुनर्मूल्यांकन स्वचालित रूप से व्यवस्था के पुनर्मूल्यांकन पर जोर देता है, हालांकि, यह पहले से ही काफी स्पष्ट है। सामान्य तौर पर, पहला निष्कर्ष यह है: यदि आपके नियंत्रण में कुछ ऐसी संपत्ति है, जो परिवर्तित होने पर, बच्चे के नियंत्रण के आकार और / या प्लेसमेंट को बदल सकती है, तो आपको इसे डिपेंडेंसीप्रोपरेटी बनाना चाहिए और AffectsMeasure / AffectsArrange फ्लैग सेट करना चाहिए। यदि इस संपत्ति के मूल्य में प्रत्येक परिवर्तन नियंत्रण को फिर से अमान्य करने की आवश्यकता नहीं है, तो यह बेहतर है कि ऐसा न करें, लेकिन दिए गए मान के साथ DependencyProperty करने के लिए, यदि आवश्यक हो, तो InvalidateMeasure / InvalidateArrange को मैन्युअल रूप से कॉल करें ताकि अनावश्यक काम के साथ WPF को अधिभार न दें।

अब सॉफ्टवेयर डिजाइन के संदर्भ में इन दो तरीकों पर विचार करें। वह है - जिम्मेदारी और इनपुट / आउटपुट डेटा के उनके क्षेत्र क्या हैं। यह समझने में शायद सबसे महत्वपूर्ण बात है कि WPF लेआउट सिस्टम कैसे काम करता है। इस विषय का स्वाद लेने में मुझे व्यक्तिगत रूप से बहुत समय लगा। मैं भी WPF के स्रोत कोड में तल्लीन करना था, क्योंकि वे उपलब्ध हैं।

उपाय और व्यवस्था

माप के लिए प्रलेखन इस तरह से लिखा गया है कि ऐसा लगता है कि यह पूरी तरह से सूचनात्मक चरण है और प्रदर्शन को प्रभावित नहीं करना चाहिए। सब कुछ तर्कसंगत लगता है - माता-पिता का नियंत्रण बच्चों को सर्वेक्षण करता है, उनसे पता लगाता है कि वे कितना कब्जा करना चाहते हैं, ठीक है, यह विशेष रूप से तय करता है कि किसको कितना स्थान काटना है, और कॉल की व्यवस्था करें । सामान्य तौर पर, PresentationCore स्तर पर, यह मामला होता है (वहां UIElement में खाली वर्चुअल मेथड्स मापक और ArrangeCore शामिल हैं), लेकिन हम सबसे अधिक विशिष्ट व्यवहार में रुचि रखते हैं, FrameworkElement और उसके वंशज के व्यवहार और फ्रेमवर्क को पहले से ही PresentationFramework विधानसभा में परिभाषित किया गया है।

मैं इसे स्पष्ट रूप से और सही ढंग से बनाने की कोशिश करूंगा क्योंकि मैं यह कर सकता हूं। यदि गलतियाँ या त्रुटियां हैं, तो सही, मैं परिवर्तन करूँगा।

सार्वजनिक शून्य उपाय (आकार उपलब्ध आकार) - एक विधि, जो उपलब्ध है, को दिया गया, वांछित आकार निर्धारित करता है और उन्हें इस पर सेट करता है। विधि का वर्णन कहता है कि परिणामी DesiredSize> availableSize हो सकता है, लेकिन यह फ्रेमवर्क वंशावली वंश के लिए ऐसा नहीं है।
उपाय विधि का सार निम्नलिखित चीजें करना है:

1. सभी VisualChild तत्वों के लिए पुनरावर्ती कॉल करें (अन्यथा IsMeasureValid ध्वज उनके लिए सेट नहीं किया जाएगा और बच्चा तत्व खींचा नहीं जा सकेगा)। उपाय को कम से कम एक बार बुलाया जाना चाहिए। उपाय को बार-बार कहा जा सकता है (उदाहरण के लिए, आप पहले माप को तर्क के साथ कॉल कर सकते हैं = नियंत्रण के पूर्ण आकार को निर्धारित करने के लिए Double.PositiveInfinity ) और माप को अंतिम कॉल उन आयामों के साथ किया जाना चाहिए जो वास्तव में इस बच्चे के नियंत्रण को आकर्षित करने के लिए उपयोग किया जाएगा।
2. नियंत्रण की स्थिति तैयार करें ताकि यह उपलब्ध आयामों में फिट हो। यही कारण है कि माप को अंतिम कॉल तत्व के वास्तविक आयामों को निर्धारित करना चाहिए। इसका कारण यह है कि यदि नियंत्रण वांछित मान को निर्धारित करता है जो उपलब्ध से अधिक है, तो निश्चित आकार वाले ग्रिड सेल को पता नहीं होगा कि क्या करना है। ऐसा लगता है कि निश्चित आकार है, लेकिन नहीं - बच्चा मेज पर उसकी मुट्ठी पीट रहा है और अधिक चाहता है! इसलिए, जो प्रलेखन वाक्यांश उपलब्ध है, वह एक 'नरम बाधा' है, जो कि FrameworkElement के संदर्भ में कड़ाई से गलत बोल रहा है।

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

वैसे, बिल्कुल फ्रेमवर्क क्यों? क्या प्रकाश उस पर अभिसिंचित है? यह पता चला है कि यह वास्तव में अभिसरण किया गया है, और FrameworkElement UIElement.MeasureCore और UIElement.ArrangeCore को सील किए गए संशोधक के साथ ओवरराइड करता है, अर्थात, फ्रेमऑमेंट के सभी वंशज (सभी नियंत्रण, विंडोज़, आदि) यदि वे चाहें तो मापनकोर और अरेंजकोर के व्यवहार को बदलने में सक्षम नहीं होंगे। वे केवल इच्छाएं छोड़ सकते हैं - इसके लिए मीज़ोएवर्राइड और अरेंज ऑवरराइड विधियां बनाई गई हैं। और अब मेजरऑवरराइड में उपलब्ध हैसलाइज वास्तव में एक नरम बाधा है, और आप कानूनी रूप से एक मान लौटा सकते हैं जो तर्क के मूल्य से अधिक है।

public void Arrange (Rect finalRect) - बस नियंत्रण को उसका स्थान (x, y) और आयत का आकार बताता है। इन सीमाओं से परे जाने वाली हर चीज का खतना किया जाएगा।

माप और व्यवस्था के बीच निम्न संबंध है - आदर्श रूप से, माप के अंतिम कॉल को एक आकार लेना चाहिए जो अगली कॉल के आकार को अरेंज करने से मेल खाता है। यदि ऐसा है, तो नियंत्रण पूरी तरह से खींचा जाएगा। यदि स्थिति पूरी नहीं होती है, तो समस्याएं हो सकती हैं। यही है, यह संभव है कि सब कुछ सही ढंग से प्रदान किया जाएगा, और शायद बिल्कुल नहीं। उदाहरण के लिए, इस स्थिति में, सूचीबॉक्‍स (जब व्‍यवस्‍था करें <मापी करें) नूर दाईं ओर (स्‍क्रॉलबार स्‍लाइड में बॉर्डर के साथ बाईं ओर ले जाता है, लेकिन क्रॉप नहीं किया जाता है), और नीचे - क्रॉप किया जाता है।

अब यह मापने के तरीकों पर विचार करने के लिए बना हुआ है।

मीसोवरराइड और अरेंजऑवरराइड

संरक्षित वर्चुअल साइज मेजोवरराइड (आकार उपलब्ध है) डेवलपर्स को अपने स्वयं के प्लेसमेंट लॉजिक के साथ नियंत्रण कक्ष बनाने के लिए सक्षम करने के लिए डिज़ाइन किया गया है। आमतौर पर, मापने वाले एल्गोरिथ्म को निम्न चरणों का पालन करना चाहिए:

1. बच्चों के पूर्ण आकार का अनुमान लगाएं - मापदंडों के साथ मापने के लिए एक पुनरावर्ती कॉल के द्वारा आकार। चौड़ाई और आकार। प्रकाश = डबल।पोसिटिव इनफिनिटी
2. बच्चों के आकार के अनुसार अपना पूरा आकार दें
3. यदि हम उपलब्ध हो जाते हैं, तो हम अपने पूर्ण आकार का मान लौटाते हैं
4. अन्यथा, हमें बच्चों में फिर से माप को कॉल करने की आवश्यकता हो सकती है, लेकिन पॉजिटिवइन्फिनिटी के साथ नहीं, बल्कि विशिष्ट मूल्यों के साथ, हमारे लिए आवंटित उपलब्ध आकार में फिट होने के लिए। इस चरण का विशिष्ट कार्यान्वयन प्लेसमेंट तर्क पर निर्भर करता है जिसे हम लागू करना चाहते हैं।
5. यदि हम उपलब्ध होने का प्रबंधन करते हैं, तो हम उपलब्ध कराए गए विवरणों को उपलब्ध कराएं। यदि हम उपलब्ध, प्रबंधन, या उपलब्ध मूल्य से अधिक न्यूनतम मूल्य के भीतर रखने का प्रबंधन करते हैं, जो हमारे नियंत्रण को पूरी तरह से प्रदान करेगा।

संरक्षित आभासी आकार ArrangeOverride (आकार को अंतिम रूप दें) - और यहां हम संबंधित सीमाओं और स्थिति के साथ प्रत्येक बच्चे के तत्व के लिए व्यवस्था पद्धति को कॉल करते हैं।

ध्यान दें कि उपलब्ध से अधिक से अधिक मूल्य को मापा जा सकता है । लेकिन यदि आप ऐसा करते हैं और DesiredSize नियंत्रण की जांच करते हैं, तो हमें आश्चर्य होगा कि DesiredSize = availableSize। यही है, किसी ने हमारे परिणाम को नजरअंदाज कर दिया और वहां उपाय तर्क का मूल्य लिखा। हालाँकि, जब ArrangeOverride को आगे एक तर्क के रूप में कहा जाता है, हम फिर से जादुई रूप से अपना मूल्य प्राप्त करते हैं, जिसे हम मेजरओवराइड से लौटाते हैं ।

क्या चल रहा है? और यही होता है।

अगर FrameworkElement। मर्जर को अनंत स्थिरांक के साथ कहा जाता है, तो हमारे मेज़रव्यूड्राइड रिटर्न की परवाह किए बिना , FrameworkElement.MeasureCore इसे क्रॉप करेगा और DesiredSize <= availableSize सेट करेगा । और घर पर हमारे DesiredSize कैश, बाद में इसे ArrangeOverride में हमारे पास भेज रहे हैं। ऐसा इसलिए है क्योंकि FrameworkElement यह सुनिश्चित करता है कि जब आप उपाय कहते हैं, तो यह उसके लिए आवंटित किए गए टुकड़े में फिट होगा, भले ही उसे हमारी सामग्री को काट देना पड़े।

अन्यथा, यह मामला होगा कि विशिष्ट चौड़ाई / ऊंचाई के मूल्यों के साथ ग्रिड कोशिकाएं नियंत्रण पर चली जाएंगी जो कि DesiredSize > availableSize को लौटा देती हैं। और यह पता चलता है कि FrameworkElement DesiredSize के लिए वास्तविक आवश्यकताओं को बरकरार रखता है, और जब अरेंज समय आता है, तो यह हमारे ArrangeOverride पद्धति को DesiredSize मान के साथ कॉल करता है जो हम मेजरओवराइड पर लौट आए। और हम ArrangeOverride पर बच्चों की व्यवस्था करना चाहते हैं।
उसके बाद, FrameworkElement.ArrangeCore , जिसके संदर्भ में हमारा ArrangeOverride कहा जाता है , हमारी सामग्री को क्लिप करता है, और हम ग्रिड में अपने नियंत्रण का हिस्सा देखते हैं। और कौन सा भाग क्षैतिज / वर्टिकल एलिगमेंट और अन्य के गुणों पर निर्भर करता है। लेकिन सामग्री वास्तव में पूरी तरह से प्रदान की जाती है जैसा कि हम चाहते थे - क्योंकि हमारा DesiredSize सहेजा गया था और ArrangeOverride पर स्थानांतरित किया गया था।

और फ्रेमवर्क के वारिस को लागू करते समय , हमें ऐसी स्थितियों में क्लिपिंग के बारे में चिंता करने की ज़रूरत नहीं है - वह हमारे लिए सब कुछ करेगा। और अगर हमें किसी ऐसे पैनल की आवश्यकता है जो DesiredSize > availableSize को प्रोसेस करता है, तो हम या तो कुछ गलत कर रहे हैं, या हमें UIElement को एक स्तर नीचे जाना होगा, जो कि ( CoreCoreCoreCoreCore ) और ArrangeCore को अंतिम रूप नहीं देता है ।

इन सभी का परीक्षण करने के लिए, आप एक बटन इनहेरिटर बना सकते हैं और एक निश्चित आकार को मेजरऑवर्राइड पर लौटा सकते हैं , और बटन को छोटे आकार (जैसे, 50x50) के साथ ग्रिड सेल में डाल सकते हैं। बटन काटा जाएगा।

protected override Size MeasureOverride(Size constraint) {
return new Size(80, 80);
}

यह सुविधा http://social.msdn.microsoft.com/ पर वर्णित है

अंत में, मैं चर्चा की गई सामग्री से संबंधित WPF स्रोतों (UIElement और FrameworkElement classes) से कुछ तरीकों के लिए कोड लाना चाहूंगा। टिप्पणियों को पर्याप्त विस्तार से सार के साथ टुकड़े करें।

WPF के लिए संपूर्ण स्रोत कोड यहां से डाउनलोड किया जा सकता है (डाउनलोड .Net - 4)।

UPD: afsherman आपको बताता है कि WPF स्रोत वैकल्पिक हैं। किसने स्थापित किया ReSharper स्रोत को डाउनलोड करने के लिए अंतर्निहित विकल्प का उपयोग Ctrl + द्वारा किया जा सकता है वर्ग (विधि / संपत्ति, आदि) के नाम पर क्लिक करें।