डेल्फी: आवेदन क्या है। हैंडल?

Question

TApplication.Handle क्या है?

• यह कहां से आता है?
• यह क्यों मौजूद है?
• और सबसे महत्वपूर्ण बात यह है कि सभी रूपों में यह उनके मूल विंडो हैंडल के रूप में क्यों है?

डेल्फी मदद का कहना है:

TApplication.Handle

प्रदान करता है विंडो तक पहुंच आवेदन का मुख्य रूप (विंडो) की संभाल।

property Handle: HWND; 

विवरण

उपयोग हैंडल जब Windows API कार्यों एक माता पिता खिड़की संभाल की आवश्यकता है कि बुला। उदाहरण के लिए, एक डीएलएल प्रदर्शित करता है जो अपने स्वयं के शीर्ष-स्तरीय पॉप-अप विंडो को पेरेंट विंडो की आवश्यकता होती है एप्लिकेशन में अपनी विंडो प्रदर्शित करती है। हैंडल प्रॉपर्टी का उपयोग एप्लिकेशन के ऐसे विंडोज भाग को बनाता है, ताकि वे कम से कम, पुनर्स्थापित, सक्षम और एप्लिकेशन के साथ अक्षम हो जाएं।

तो मैं शब्दों पर "आवेदन का मुख्य रूप से खिड़की संभाल" ध्यान देते हैं, और मैं कि ले मतलब करने के लिए आवेदन का मुख्य रूप से खिड़की संभाल, तो मैं तुलना कर सकते हैं :

• "अनुप्रयोग का मुख्य रूप से खिड़की संभाल",
• Application

की MainForm की खिड़की हैंडल

लेकिन वे एक ही नहीं कर रहे हैं:

Application.MainForm.Handle: 11473728 
Application.Handle: 11079574 

तो Application.Handle क्या है?

• यह कहां से आता है?
• क्या विंडोज ® विंडो हैंडल है?
• यदि यह के MainForm की विंडो हैंडल है, तो वे क्यों मेल नहीं खाते हैं?
• यदि यह Application के MainForm की विंडो हैंडल है, तो यह क्या है?
• अधिक महत्वपूर्ण बात यह है कि यह हर रूप का अंतिम अभिभावक क्यों है?
• और सबसे महत्वपूर्ण: अगर मैं एक फॉर्म को अनपेक्षित करने की कोशिश करता हूं तो सब कुछ क्यों खराब हो जाता है (इसलिए मैं टास्कबार पर दिखाई दे सकता हूं), या आईपी प्रोग्रेसडियलॉग जैसे कुछ उपयोग करने का प्रयास करें?

वास्तव में मैं जो पूछ रहा हूं वह है: डिज़ाइन तर्क क्या है जो एप्लिकेशन बनाता है। हैंडल मौजूद है? अगर मैं समझ सकता हूं कि क्यों, स्पष्ट होना चाहिए।

---

अद्यतन बीस प्रश्नों की एक खेल के माध्यम से समझना:

यह:

एक खिड़की बनाने का समाधान के बारे में बात में उसके मालिक null, Peter Below in 2000 said बनाकर कार्य पट्टी पर दिखाई देते हैं माध्यमिक रूपों से दिखाए गए मोडल रूपों के साथ कुछ समस्याएं पैदा कर सकती हैं।

यदि उपयोगकर्ता एक मोडल फॉर्म के ऊपर ऐप से दूर स्विच करता है, और उसके बाद इसे दिखाए गए फॉर्म पर वापस ले जाता है, तो मोडल फॉर्म फ़ॉर्म के नीचे छिपा सकता है। यह सुनिश्चित करें कि मोडल प्रपत्र फार्म का है कि यह पता चला है parented है बनाकर इस से निपटने के लिए (का उपयोग कर `ऊपर के रूप में params.WndParent``)

संभव है लेकिन इस से मानक संवादों साथ संभव नहीं है Dialogs इकाई और अपवाद, जो के लिए और अधिक प्रयास की जरूरत है उन्हें सही काम करने के लिए मिलता है (मूल रूप से Application.OnActivate, निपटने GetLastActivePopup के माध्यम से आवेदन को parented मोडल रूपों की तलाश में और SetWindowPos के माध्यम से जेड क्रम के शीर्ष पर उन्हें लाने) ।

• क्यों एक मॉडल फार्म खत्म करता है अन्य रूपों के पीछे अटक?
• कौन सी तंत्र आम तौर पर सामने के लिए एक मॉडल रूप लाती है, और यह यहां क्यों कार्यात्मक नहीं है?
• विंडोज ® विंडोज़ स्टैक्ड दिखाने के लिए ज़िम्मेदार है। क्या गलत हो गया है कि विंडोज ® सही खिड़कियां नहीं दिखा रहा है?

उन्होंने यह भी टास्कबार पर प्रकट करने के लिए (जब बनाने यह संयुक्त राष्ट्र के स्वामित्व वाली के सामान्य नियम, अपर्याप्त अव्यावहारिक, या अवांछनीय है) नए विंडोज बढ़ाया शैली है कि एक खिड़की बलों का उपयोग कर के बारे में बात WS_EX_APPWINDOW बढ़ाया जोड़कर शैली:

procedure TForm2.CreateParams(var Params: TCreateParams); 
begin 
    inherited CreateParams(params); 

    Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW; 
end; 

लेकिन फिर वह चेतावनी देते हैं:

आप टास्कबार बटन एक माध्यमिक रूपों पर क्लिक करते हैं, जबकि एक अन्य एप्लिकेशन सक्रिय यह अभी भी सभी अनुप्रयोगों च लाएगा है सामने के लिए ओएमएस। आपको बस इतना यदि नहीं चाहते विकल्प

कौन सामने से सभी रूपों ला रहा है जब प्रपत्र के मालिक अभी भी Application.Handle है नहीं है। आवेदन यह कर रहा है? यह ऐसा क्यों कर रहा है?ऐसा करने के बजाय, इसे नहीं ऐसा नहीं करना चाहिए? का नकारात्मक पक्ष ऐसा नहीं कर रहा है; मैं देख का नकारात्मक पहलू कर यह (सिस्टम मेनू के propertly काम नहीं करते, टास्कबार बटन थंबनेल गलत हैं, विंडोज ® खोल खिड़कियां कम से कम नहीं कर सकते

---

एक और पोस्ट में, Application के साथ काम कर Mike Edenfield says that the parent window sends other window's their minimize, maximize and restore messages:।

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

procedure WMSysCommand(var Msg: TMessage); WM_SYSCOMMAND; 

procedure TParentForm.WMSysCommand(var Msg: TMessage); 
begin 
    if Msg.wParam = SC_MINIMIZE then 
    begin 
     // Send child windows message, don't 
     // send to windows with a taskbar button. 
    end; 
end; 

ध्यान दें कि यह हैंडलर के स्वतंत्र रूप से एक आप व्यवहार करने के लिए चाहते हैं के PARENT रूप में चला जाता है>: इस से बचने के लिए, आप इस तरह के रूप में एक पंक्ति जोड़कर WM_SYSCOMMAND के लिए संदेश हैंडलर स्थापित कर सकते हैं शेष आवेदन, ताकि कम से कम संदेश पर गुजरने से बचें। आप, आदि SC_MAXIMIZE, SC_RESTORE के लिए इसी तरह के> कोड जोड़ सकते हैं

कैसे है यह है कि कम से कम/अधिकतम/मेरे Windows ® खिड़कियों के लिए संदेशों को बहाल अपनी खिड़की के लिए नहीं जा रहे हैं? क्या ऐसा इसलिए है क्योंकि विंडो के मालिक के लिए Windows ® द्वारा विंडो के लिए नियत संदेश भेजे जाते हैं? और इस मामले में डेल्फी आवेदन में सभी रूप Application द्वारा "स्वामित्व" हैं? इसका मतलब यह नहीं है कि करता है मालिक अशक्त बनाने कि:

procedure TForm2.CreateParams(var Params: TCreateParams); 
begin 
    inherited; 
    Params.WndParent := 0; //NULL 
end; 

Application निकाल देंगे और मेरे रूप में हस्तक्षेप करने से यह की खिड़की हैंडल, और Windows एक बार फिर से मुझे भेजना चाहिए मेरी mimimize/अधिकतम/संदेशों को बहाल?

---

शायद अगर हम तुलना और विषम अब एक "सामान्य" विंडोज़ अनुप्रयोग बातें, कैसे बोर्लेन्ड शुरू में डेल्फी अनुप्रयोगों काम करने के लिए तैयार किया गया है के साथ करता है - इस Application वस्तु के संबंध में है और यह मुख्य पाश है।

• Application ऑब्जेक्ट हल करने का क्या समाधान था?
• डेल्फी के बाद के संस्करणों के साथ क्या परिवर्तन किया गया था ताकि ये वही मुद्दे मौजूद न हों?
• क्या डेल्फी के बाद के संस्करणों में परिवर्तन अन्य समस्याओं का परिचय नहीं दिया गया था, कि प्रारंभिक अनुप्रयोग डिजाइन को हल करने के लिए इतना कठिन प्रयास किया गया था?
• उन नए एप्लिकेशन अभी भी उनके साथ हस्तक्षेप किए बिना आवेदन कैसे कर सकते हैं?

स्पष्ट रूप से बोर्लैंड ने अपने प्रारंभिक डिजाइन में दोष को महसूस किया। उनका प्रारंभिक डिज़ाइन क्या था, यह किस समस्या को हल कर रहा था, दोष क्या था, फिर से डिजाइन क्या था, और यह समस्या को कैसे हल करता है?

Answer 1

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

यह है कि हम कैसे "समस्या" जहां खिड़कियों मुख्य मेनू से युक्त बहुत कम ही ऐसा करने के लिए फ़ाइल मेनू बस काम नहीं होगा Alt-एफ प्रसंस्करण इतना ध्यान केंद्रित किया गया था हल है। इस केंद्रीय पार्किंग खिड़की को मध्यस्थ के रूप में उपयोग करके, हम आसानी से उचित खिड़कियों के संदेशों को ट्रैक और रूट कर सकते हैं।

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

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

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

Answer 2

forms.pas (डेल्फी 2009) में स्रोत पर देख से, ऐसा लगता है कि वे Win32 जीयूआई क्षुधा में एक "मास्टर" विंडो बनाने के लिए

• TApplication कॉल अनुमति देने के लिए।कम से कम
• TApplication.Restore
• आदि

ऐसा लगता है कि Application.Handle को पारित कर दिया संदेश, MainForm करने के लिए उपयुक्त के रूप में भेजा जाता है यदि वह मौजूद है। यदि ऐप को मुख्य विंडो नहीं बनाया गया है तो यह ऐप को कम करने, आदि को प्रतिक्रिया देने की अनुमति देगा। प्रोजेक्ट स्रोत को संशोधित करके आप एक डेल्फी ऐप बना सकते हैं बिना एक मुख्य विंडो।

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

अपने प्रश्नों के अनुसार:

• यह कहाँ से आता है? यह एक खिड़की के हैंडल TApplication.Create

• यह क्या विंडोज़ संभाल है में बन जाता है? एक नकली खिड़की है कि हर जीयूआई डेल्फी एप्लिकेशन TApplication अमूर्त

• के हिस्से के रूप की आवश्यकता है यह appliation के मुख्य रूप की खिड़कियों संभाल नहीं

• अपने आवेदन के MainForm के हत्थे नहीं तो क्या तो है क्या यह? ऊपर देखें

• अधिक महत्वपूर्ण बात: यह हर रूप का अंतिम अभिभावक क्यों है? यह मानते हुए कि आप सही हैं कि यह परम माता-पिता है, मुझे लगता है कि ऐसा इसलिए है क्योंकि यह आपके आवेदन में सभी रूपों को ढूंढना आसान बनाता है (इस "मास्टर" फॉर्म के बच्चों की गणना करना)।

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

वैसे भी, यह मेरा है। आप forms.pas में टीएप्लिकेशन घोषणा और कोड को देखकर शायद अधिक जान सकते हैं। मैं जो देखता हूं उससे नीचे की रेखा यह एक सुविधाजनक अमूर्त है।

सादर,

डॉन

Answer 3

सभी VCL क्षुधा एक "छिपा" शीर्ष स्तर खिड़की आवेदन कहा जाता है। यह स्वचालित रूप से एप्लिकेशन स्टार्टअप पर बनाया गया है। अन्य चीजों में से यह वीसीएल के लिए मुख्य विंडोज़ संदेश हैंडलर है - इसलिए आवेदन। प्रोसेस मैसेज।

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

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

में पर्दे के पीछे होने