ऐसा लगता है कि किसी प्रकार के ऑब्जेक्ट को तुरंत चालू करने के लिए एक टीकंपोनेंट को मालिक के रूप में पूरी तरह से अप्रासंगिक लगता है। इतने सारे डेल्फी घटक क्यों हैं जिनके लिए इसकी आवश्यकता है?क्यों कुछ डेल्फी घटकों को बनाने के लिए "AOwner: TComponent" की आवश्यकता है?
उदाहरण के लिए, TXMLDocument को तत्काल करने के लिए एक TComponent ऑब्जेक्ट की आवश्यकता होती है।
यह क्यों है और यदि कोई अच्छा कारण है, तो मुझे "सही चीज़ करने" के लिए क्या उपयोग करना चाहिए?
मालिक घटक अपने सभी स्वामित्व वाले घटकों का प्रबंधन करना चाहता है। मालिक नष्ट होने पर स्वामित्व वाले घटक स्वचालित रूप से नष्ट हो जाते हैं।
यह डेवलपर को टूल-पैलेट से घटकों को ड्रैग करने में मदद करता है, उन्हें फॉर्म पर छोड़ देता है और घटकों को जीवन भर के प्रबंधन के बारे में चिंता किए बिना अपने काम को पूरा करने के लिए घटनाओं को हुक करता है।
फॉर्म इस पर गिराए गए सभी घटकों का मालिक है। एप्लिकेशन ऑब्जेक्ट फॉर्म का मालिक है। जब ऐप बंद हो जाता है तो एप्लिकेशन ऑब्जेक्ट नष्ट हो जाता है जो बदले में रूपों और सभी घटकों को नष्ट कर देता है।
लेकिन एक घटक बनने पर मालिक वास्तव में आवश्यक नहीं है। यदि आप पैरामीटर को नील पास करते हैं, तो घटक मालिक के बिना बनाया जाएगा और इस मामले में घटक के जीवनकाल को प्रबंधित करने की आपकी ज़िम्मेदारी होगी।
सभी टीकंपोनेंट वंशजों को मालिक की आवश्यकता होती है, इसे टीकंपोनेंट कन्स्ट्रक्टर में परिभाषित किया जाता है। मालिक घटक सभी स्वामित्व वाले घटकों को नष्ट करने के लिए ज़िम्मेदार है।
यदि आप जीवनकाल को नियंत्रित करना चाहते हैं, तो आप पैरामीटर के रूप में शून्य पास कर सकते हैं।
बस कुछ अतिरिक्त जानकारी जोड़ने के लिए।
प्रत्येक नियंत्रण में माता-पिता भी होते हैं। (एक TWINControl)। जहां मालिक जीवन भर का ख्याल रखता है, माता-पिता वस्तु को दिखाने का ख्याल रखता है।
उदाहरण के लिए एक फॉर्म में एक पैनल है और पैनल में एक बटन है। उस स्थिति में, फॉर्म पैनल और बटन का मालिक है। लेकिन फॉर्म पैनल का अभिभावक है और पैनल बटन का अभिभावक है।
हां, लेकिन सभी घटकों (टीकंपोनेंट) नियंत्रण नहीं हैं (टीकंट्रोल)। TControl TComponent से उतरता है। एक घटक जो नियंत्रण नहीं है, उसके माता-पिता नहीं होते हैं। –
यह भी ध्यान देने योग्य है कि यदि आप माता-पिता को नष्ट करते हैं, तो बच्चे भी नष्ट हो जाएंगे, भले ही उनके माता-पिता के स्वामित्व न हों। –
इसके बारे में जागरूक होने के लिए कुछ और भी है। मैंने कुछ तीसरे पक्ष के घटकों का उपयोग किया है जो कन्स्ट्रक्टर निर्माण में पारित एक मालिक घटक पर पर भरोसा करते हैं, और यदि आप नील में पास करते हैं तो अपवाद/एवी फेंक देंगे।
शुद्ध परिणाम यह है कि जब आप आईडीई के भीतर दृश्यमान रूप से उपयोग करते हैं तो ये घटक ठीक काम करेंगे, लेकिन रन-टाइम पर बनाए जाने पर समस्याएं पैदा होती हैं।
इन समस्याओं का कारण, एक अर्थ में, खराब डिजाइन है। नियमों में कुछ भी नहीं है कि आप एनओएल में ऑउनर पैरामीटर के रूप में पास नहीं कर सकते/नहीं।
ऑब्जेक्ट आवश्यक नहीं है एक tComponent AOwner के रूप में पारित किया जाना चाहिए। आप आसानी से इस तक पहुंच सकते हैं और खुद को विनाश को संभालने में सक्षम हो सकते हैं। अक्सर, मैं इस तकनीक का उपयोग स्थानीयकृत दिनचर्या के लिए करता हूं जहां उपयोग किए जाने वाले घटक का उपयोग वर्तमान विधि के बाहर नहीं किया जाएगा।उदाहरण के लिए:
Procedure TForm1.Foo;
var
XmlDoc : tXmlDocument;
begin
XmlDoc := tXmlDocument.Create(nil);
try
// do processing of the XMLDoc here
finally
FreeAndNil(XmlDoc);
end;
end;
'TXMLDocument' एक विशेष मामला है। जब आप अपने कंस्ट्रक्टर के लिए 'शून्य' स्वामी को पास करते हैं, तो ऑब्जेक्ट संदर्भ-गिनती इंटरफ़ेस के रूप में कार्य करता है, घटक नहीं! इस प्रकार, आपको उस संदर्भ संख्या को सही ढंग से बनाए रखने के लिए ऑब्जेक्ट को 'IXMLDocument' इंटरफेस चर पर ऑब्जेक्ट असाइन करना होगा। इस व्यवहार को सहायता में दस्तावेज किया गया है। चूंकि आपको उस मामले में 'IXMLDocument' का उपयोग करना है, इसलिए आप' TXMLDocument' को मैन्युअल रूप से तत्काल करने के बजाय 'NewXMLDocument()' और संबंधित कार्यों का उपयोग करना बेहतर कर रहे हैं। –
आप इस दो कारणों के लिए उपयोग करें shoudl: - स्वामित्व तंत्र डेल्फी क्रमबद्धता प्रक्रिया (Stream.ReadComponent/WriteComponent आदि में महत्वपूर्ण है - स्वामित्व तंत्र कचरा एकत्र करने प्रणाली का एक प्रकार के रूप में भी खड़ा है)।
एक मालिक पैरामीटर केवल TComponent वंश के लिए आवश्यक है, क्योंकि यह TComponent कन्स्ट्रक्टर का पैरामीटर है। TForm, TFrame, और TDataModule कक्षाओं पर TComponent वंशजों (जिसमें TXMLDocument शामिल हैं) पर ड्रॉप करने के लिए डिज़ाइन-टाइम पर पहुंचने वाले सभी घटक।
ग्रेट उत्तर। तो अगर मैं अपने जीवनकाल को स्वयं प्रबंधित करना चाहता हूं, तो मैं यह कैसे सुनिश्चित करूंगा कि जब मैं इसके साथ काम करता हूं तो एक वस्तु नष्ट हो जाती है? – Dave
@prapin: थोड़ा सुधार आवश्यक है: एप्लिकेशन ऑब्जेक्ट केवल फ़ॉर्म के मालिक है यदि फॉर्म एप्लिकेशन के साथ बनाया गया है। क्रेटफॉर्म(), या जब एप्लिकेशन को ऑनर के रूप में बनाने के लिए पास किया गया है। एक फॉर्म किसी अन्य रूप, या उस मामले के लिए किसी अन्य घटक के स्वामित्व में हो सकता है। – mghie
@ डेव: एसओ सवालों के बाद ऑब्जेक्ट स्वामित्व के साथ सौदा: http://stackoverflow.com/questions/398137/what-is-the-best-way-to-do-nested-try-and-finally-statement-in- डेल्फी # 3 9 860, http://stackoverflow.com/questions/415958/how-to-automatically- फ्री-classes-objects#415990 – mghie