डेल्फी, फ्रेम बनाम रूपों। मल्टी-दस्तावेज़ इंटरफ़ेस के लिए क्या?

Question

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

TFrame पर फ़ॉर्म एम्बेड करते समय TFrames का उपयोग करने के पेशेवर क्या हैं? अब तक मैं किसी भी पता नहीं, स्विचिंग केवल मुझे कोड के कुछ भागों के पुनर्लेखन के लिए की आवश्यकता होगी ...

(मैं डिजाइन समय में एम्बेड करने का उपयोग करने के लिए वैसे भी नहीं जा रहा हूँ!)

अग्रिम

धन्यवाद

Answer 1

टिप्पणी का जवाब क्यों फ्रेम का उपयोग करने के लिए एक कारण प्रदान करने के लिए: डिजाइन समय के साथ

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

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

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

ओटीओएच मुझे किसी फ्रेम को एम्बेड करने वाले किसी भी फ्रेम को एम्बेड करने के किसी भी नुकसान की जानकारी नहीं है।

संपादित करें:

OnCreate या OnShow फ्रेम की जरूरत नहीं है कि इस तरह की घटनाओं के बारे में एक टिप्पणी नहीं है। असल में, मैं फ्रेम के एक और लाभ पर विचार करता हूं, क्योंकि ईवेंट हैंडलर के पास पैरामीटर नहीं होते हैं, इसलिए बहुत सारी चीजें फॉर्म में हार्ड-कोडित होती हैं, जरूरी है।

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

निहित वस्तुओं के लिए जो घटक नहीं हैं और जीवन भर में प्रबंधित होने की आवश्यकता है, उदाहरण के लिए AfterConstruction और BeforeDestruction हैं।

Answer 2

फ़्रेम अच्छे होते हैं जब आप किसी फ़ॉर्म में "उप-फ़ॉर्म" कई बार दोहराना चाहते हैं। मैं उन्हें टैब्ड इंटरफेसिंग के लिए उपयोग नहीं करता, क्योंकि एम्बेडेड फॉर्म एमडीआई/टैब्ड इंटरफ़ेस उपयोग के लिए एक बेहतर समाधान है।

Answer 3

हो सकता है कि आप इस थ्रेड में कुछ जवाब मिल जाएगा: gui-design-multiple-forms-vs-simulated-mdi-tabs-vs-pagecontrol

Answer 4

मेरे कुछ अनुप्रयोगों में से एक के लिए कुछ साल पहले मेरा निर्णय था, हम इसे एम्बेडेड फॉर्म दिखाना चाहते थे, पहले मैंने फ्रेम्स का इस्तेमाल किया और मैंने इसे प्रबंधित करने के लिए एक कक्षा लिखी।

बाद में मुझे LMDTools से TLMDDisplayForm घटक मिला, जो इसके अंदर एम्बेडिंग फॉर्म को बहुत आसान काम करता है, यह इस्तेमाल किए गए कोड को कम करता है और हमारे पास और अधिक सुविधाएं हैं।

मुख्य लक्ष्यों में से एक जिसे हमने फ्रेम से फॉर्म में बदल दिया था, में टीएफओआर की कुछ घटनाएं गायब थीं: ऑनक्रेट, ऑनशो, ऑनएक्टिव जो हम अपने अनुप्रयोगों में कुछ कार्यों के लिए उपयोग करते हैं, जैसे कि कुछ गुणों को खोने के अलावा: ActiveControl और अन्य चीजें I याद नहीं है

आप फ़ॉर्म के साथ जाना चाहते हैं, तो मैं सुझाव है कि आप LMDTools जो आपके लिए आसान काम करते हैं, उपयोग करने के लिए बगल में मूल संस्करण मुक्त :-)

Answer 5

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

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

Answer 6

फ्रेम सबसे तेज़ लोड का उपयोग करें और फ्रेम बनाने के दौरान देरी के बिना।

लेकिन फ्रेम में माता-पिता को एम्बेड करने के लिए होना चाहिए। कोई भी क्रेट या ऑन शो घटना के साथ नुकसान ट्रिगर किया गया है। फ्रेम के निजी खंड पर

पुट:

procedure CMShowingChanged(var M: TMessage); message CM_SHOWINGCHANGED; 

और उसके बाद इस तरह कोड बनाने के लिए: लेकिन आप onShow इस तरह घटना ट्रिगर के लिए संदेश के साथ कॉल कर सकते हैं

procedure TFrame1.CMShowingChanged(var M: TMessage); 
begin 
    inherited; 
    if Showing then 
    begin 
    // .... put your code for onShowing is triggered 
    end 
    else 
    begin 
    // .... put your code for onHiding is triggered 
    end; 
end; 

आशा की मदद कर सकते हैं आप जीयूआई के लिए एम्बेडेड फ्रेम पर विचार करने के लिए।

आप अपने फ्रेम खोलने को नियंत्रित करने के लिए पेजकंट्रोल के साथ संयुक्त विचार कर सकते हैं।

मैनज़

Answer 7

मुझे लगता है कि दोनों का उपयोग किया जाना चाहिए। उदाहरण के लिए, मेरे पास एक "मानक" फ्रेम है जिसमें एक डीबीएनविगेटर, डीबीग्रीड और डेटासोर्स घटक हैं जो सामान्य डेटा ब्राउज़िंग के लिए बहुत आसान हैं। हर बार ऐसे घटकों को सम्मिलित करने के बजाय, मैं एक फ्रेम डालता हूं जिसमें अपने डेटा (जेवीसीएल: डी) के साथ कई प्रारूपों को निर्यात करने की क्षमता भी है ... लेकिन मुझे पता है कि मैं डिजाइन समय पर क्या प्रदर्शित करना चाहता हूं, इसलिए मैं बहुत सुझाव देता हूं आसान नियम: यदि यह डिजाइन समय पर जाना जाता है, तो फ्रेम का उपयोग करें, अन्यथा एम्बेडेड रूपों का उपयोग करें।

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

पूरक है कि, एक फ्रेम एक घटक है, और इसलिए, जब एक रूप में एम्बेडेड (स्वामित्व) होता है, तो फॉर्म इसके बारे में जानता है और फ्रेम फॉर्म के बारे में जानता है (इसकी विधियों और गुणों का उपयोग कर सकते हैं। एक एम्बेडेड कोई यह भी कहा कि है, लेकिन अतिरिक्त कोडिंग की आवश्यकता है)

शायद Embarcadero हमें एक TEmbeddableForm या इस तरह के उद्देश्यों के

सादर, के लिए एक इंटरफेस अलवारो Castiello