2010-01-13 12 views
5

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

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

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

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

कोको में खिड़कियों को Win32 में क्या थ्रेड एफ़िनिटी है? यानी प्रत्येक थ्रेड के पास उस धागे के स्वामित्व वाली खिड़कियों के लिए अपना संदेश प्रेषण लूप है? मुझे संदेह होना शुरू हो गया है कि शायद कोको को मेरी सभी खिड़कियों को मुख्य धागे से 'स्वामित्व' होने की उम्मीद है और मैं सिर्फ अन्य धागे पर काम (और ड्राइंग) ऑफसेट करने के लिए मिलता हूं।

कोको के प्रतिमानों के लिए एक बहु विंडो-प्रति-थ्रेड Win32 ऐप का अनुवाद करने के तरीके के बारे में कोई संकेत है?

उत्तर

9

इंटरफेस बिल्डर इस चर्चा में एक लाल हेरिंग है। असली सवाल कोको के डिजाइन पैटर्न और अपने प्रश्न से इन दो पैराग्राफ को केंद्रित है महत्वपूर्ण हैं:

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

कोको में खिड़कियां क्या आपके पास Win32 में थ्रेड एफ़िनिटी के हैं? यानी प्रत्येक धागे का अपना संदेश द्वारा स्वामित्व वाली विंडो के लिए प्रेषण लूप है? मैं पर संदेह करना शुरू कर देता हूं कि शायद कोको को मेरे विंडोज़ को मुख्य थ्रेड द्वारा 'स्वामित्व' होने की उम्मीद है और मैं बस अन्य थ्रेड पर (और ड्राइंग) काम ऑफसेट करने के लिए मिलता हूं।

संक्षेप में, नहीं, यह ऐसा काम नहीं करता है। कोको में एक पूरी तरह से अलग घटना हैंडलिंग मॉडल और Concurrency का समर्थन करने के लिए उपकरणों का एक पूरी तरह से अलग सेट है।

विशेष रूप से, कोको एक मुख्य समारोह पाश कि हमेशा मुख्य थ्रेड पर चलाता है के एक मजबूत धारणा है।यह वह जगह है जहां उपयोगकर्ता की घटनाओं को संभाला जाता है और जहां लगभग सभी चित्र आते हैं (हालांकि यह प्रतिबंध समय के साथ कम हो गया है)।

यह अलग है और थ्रेड-प्रति-खिड़की-साथ-पंप जैसे काम करने के लिए इसे मोड़ने की कोशिश करना अत्यधिक दर्द का मार्ग है। इसे नीचे मत जाओ।

अब, कोको प्रति थ्रेड रन लूप है। लेकिन वे उपयोगकर्ता घटनाओं को संसाधित करने के लिए उपयोग नहीं किया जाता है।

संक्षेप में, आपको कोको को कोड खींचने के लिए अपने आवेदन की आर्किटेक्चर पर फिर से विचार करने की आवश्यकता होगी। एक सीधी बंदरगाह संभव नहीं है।

+1

टीएल; डॉ संस्करण: "कोको एक एकल थ्रेडेड यूआई टूलकिट है जैसे डब्ल्यूपीएफ, अन्य धागे पर काम करें" –

+1

प्यारा, लेकिन गलत। मल्टीथ्रेडिंग ड्राइंग समेत बहुआयामी के लिए कोको वास्तव में समर्थन का एक गुच्छा है। ऐसा नहीं होता है कि कई धागे स्वतंत्र रूप से घटनाओं को संभालने के लिए हैं (क्योंकि, काफी हद तक, यह समझ में नहीं आता है)। – bbum

+0

@bbum मेरा मतलब है, कि जब तक आप इसे मजबूर नहीं करते, कोको के पास UI संदेशों को संसाधित करने के लिए 1 ईवेंट लूप होगा। मेरा टीएल; डॉ; संस्करण इतना अच्छी तरह से समझाया नहीं गया था, लेकिन मैं इसे छोटा रखने की कोशिश कर रहा था :) –

संबंधित मुद्दे