मेरे पास एक विंडोज फॉर्म (.NET) एप्लिकेशन है जिसमें एकाधिक दस्तावेज़ एक साथ खुल सकते हैं।विंडोज फॉर्म - एकाधिक इवेंट लूप्स
प्रत्येक दस्तावेज़ (फॉर्म) अपने स्वयं के ईवेंट लूप को चलाने के लिए सुविधाजनक होगा। संक्षिप्त प्रयोग के साथ, अपने स्वयं के एसटीए धागे में कई इवेंट लूप शुरू करना प्रतीत होता है। क्या कोई कारण है कि यह एक बुरा विचार है?
मुझे लगता है कि यह पूरी तरह से ठीक है विभिन्न धागे पर एकाधिक संदेश लूप बनाते हैं। तीसरी पार्टी यूआई टूलकिट से निपटने के लिए एकमात्र चीज देखना है, वे कभी-कभी हैंडल को स्थैतिक (थ्रेडस्टैटिक के बजाए) सदस्यों के रूप में स्टोर करते हैं और यदि आपके आवेदन में एकाधिक UI थ्रेड हैं, तो इसमें समस्याएं होंगी (मेरे मामले में, मैंने पाया कि मेनू/टूलबार कीबोर्ड त्वरक ठीक से काम नहीं करते थे)।
ऐसा करने के बड़े कारणों में से एक यह है कि यदि आपके पास मॉडेल संवाद हैं जो विभिन्न मॉडेलस संवादों पर दिखाई देते हैं। यदि आप सब कुछ एक ही संदेश लूप पर डालते हैं, तो यदि मॉडल मॉडल में से एक में एक मोडल डायलॉग होता है, तो जब तक आप मोडल डायलॉग को खारिज नहीं करते हैं, तब तक पूरा एप्लिकेशन (सभी विंडोज़) अवरुद्ध हो जाता है।
और, जैसे केविन कह रहे थे, क्रॉस-विंडो (क्रॉस-थ्रेड) कॉल के लिए देखें। आप अन्य UI थ्रेड्स पर प्रतिनिधि कॉल पोस्ट करने के लिए Control.BeginInvoke या Control.Invoke का उपयोग कर सकते हैं।
दूसरी बात यह है कि आप अपनी प्रक्रिया से कैसे बाहर निकलेंगे। आपको संदेश लूप का ट्रैक रखने की अधिक संभावना होगी ताकि जब आप सब कुछ बंद करना चाहते हैं तो आप उन्हें रोक सकते हैं। यदि आप परवाह नहीं है और बस सभी खिड़कियां बंद होने पर प्रक्रिया समाप्त होने की इच्छा है, तो आप भी ऐसा कर सकते हैं।
इंगित करने का एक अन्य लाभ यह है कि आपको प्रति संदेश लूप एक 'एप्लिकेशन। थ्रेड अपवाद' मिलता है। आप इसका उपयोग तार्किक रूप से "समूह" के साथ विंडोज़ (उदाहरण के लिए एक लॉजिकल यूज केस/वर्कफ़्लो से संबंधित सभी विंडोज़) के लिए कर सकते हैं, उन्हें एक समर्पित थ्रेड और मैसेज लूप दें, और इन थ्रेड के 'एप्लिकेशन में केवल इन विंडो से अनचाहे अपवादों को पकड़ें। थ्रेडएक्सप्शन' । – stakx
बस धागे से जीयूआई तत्वों तक पहुंचने से सावधान रहें।
आपके उद्देश्य के लिए मोडलेस फॉर्म अधिक उपयुक्त हो सकते हैं। फॉर्म का उपयोग करें। शो() फॉर्म के बजाय .ShowDialog()।
+1। क्या हर कोई ऐसा नहीं करता है? आप इस तरह से कई रूपों को दिखा सकते हैं। –
हमारे पास पहले से ही एक ही यूआई थ्रेड पर मॉडल के रूपों के साथ कई खिड़कियां हैं। इस दृष्टिकोण के साथ कुछ समस्याएं हैं जिन्हें हम पार करना चाहते हैं (हम चाहते हैं कि कुछ संवाद एक व्यक्तिगत विंडो के लिए मोडल हों लेकिन उदाहरण के लिए सभी खुले दस्तावेज़ों के लिए नहीं)। – fuzzyman
एमडीआई (एकाधिक दस्तावेज़ इंटरफेस) कंटेनर और बाल रूपों का उपयोग करना बेहतर हो सकता है। इस मामले में, प्रत्येक दस्तावेज़ अपने स्वयं के रूप में होगा, जो तकनीकी रूप से प्रत्येक दस्तावेज़ का अपना संदेश कतार है।
एमडीआई कंटेनर उपयोगकर्ता के दृष्टिकोण से भयानक हैं। – fuzzyman
एमडीआई उपयोगकर्ता पीओवी से रेडयूंडेंट है क्योंकि डेस्कटॉप एक एमडीआई कंटेनर है। –
यह सब एमडीआई के खिलाफ क्यों नफरत है ?? एमएस ऑफिस एप्स सभी एमडीआई हैं। –
आपको क्यों लगता है कि आपको एक से अधिक संदेश लूप की आवश्यकता है? एक संदेश लूप किसी भी खिड़कियों को संभाल सकता है।
यदि आप पाते हैं कि एक खिड़की में एक लंबे समय से चलने वाला ऑपरेशन पूरे ऐप को लटकाने में सक्षम है, तो उत्तर यूआई उत्तरदायी छोड़कर BackgroundWorker जैसे लंबे समय तक चलने वाले काम को विभाजित करना है।
एकाधिक धागे के साथ प्रोग्रामिंग, प्रत्येक अपने यूआई के साथ, अधिक जटिल है, क्योंकि एक थ्रेड विंडोज़ और अन्य धागे से बनाए गए नियंत्रणों तक नहीं पहुंच सकता है।
मॉडल संवाद पूरे एप्लिकेशन को अवरुद्ध करते हैं। हम उन्हें * फॉर्म (दस्तावेज़) को अवरुद्ध करने की आवश्यकता रखते हैं, जिन्हें वे कहते हैं, लेकिन पूरे एप्लिकेशन को अवरुद्ध नहीं करते हैं। – fuzzyman
आप प्रति दस्तावेज़ एक उदाहरण क्यों नहीं चलाते हैं? –
हमारा स्टार्टअप समय बहुत महंगा है और हम आईपीसी का उपयोग किए बिना दस्तावेज़ों के बीच संवाद करने में सक्षम होना चाहते हैं। वास्तव में – fuzzyman