कई JFrames का उपयोग: अच्छा या बुरा अभ्यास? [बन्द है]

Question

मैं एक एप्लिकेशन विकसित कर रहा हूं जो छवियों को प्रदर्शित करता है, और डेटाबेस से ध्वनियां बजाता है। मैं यह तय करने की कोशिश कर रहा हूं कि जीयूआई से डेटाबेस में छवियों को जोड़ने के लिए एक अलग JFrame का उपयोग करना है या नहीं।

मैं सोच रहा हूँ कि क्या कई JFrame विंडो का उपयोग करना अच्छा है?

Comments

केवल तभी यदि आप एक मल्टी-मॉनिटर सेट-अप को लक्षित कर रहे हैं!

— डीएनए

मैं यह भी तर्क दूंगा कि यह भाषा-अज्ञेयवादी है और विशेष रूप से जावा से अधिक उपयोगकर्ता-इंटरफ़ेस के साथ करना है ।

— वचर्जिन

मैं इस बात से सहमत हूँ कि @Chargin यह सवाल मेरे लिए जितना मूल्यवान था, उससे कहीं अधिक मूल्यवान बन गया है!

— बाल्ड

मुझे लगता है कि शुरुआती (जैसे खुद) आमतौर पर कई JFrames का उपयोग करते हैं। शायद इसलिए क्योंकि इसका मुख्य कार्ड जेफ्रेम के अंदर से कॉललैटआउट के उपयोग की तुलना में इसे कॉल करना आसान है। हालांकि कुछ मामलों में इसका उपयोग करने की सलाह नहीं दी जाती है।

— हुडलूम

डिबगिंग कैक्टस खाने जैसा होगा .. यह उचित नहीं है।

— तस्लीम ओसेनी

Answer 1

मैं सोच रहा हूँ कि क्या कई JFrames का उपयोग करना अच्छा है?

बुरा (बुरा, बुरा) अभ्यास।

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

---

एक जीयूआई में कई तत्वों को प्रदर्शित करने के कई तरीके हैं, जैसे:

• CardLayout(लघु डेमो। ) चलो अच्छा ही हुआ:
  1. संवाद की तरह जादूगर दिखा रहा है।
  2. संबंधित घटक वाले आइटम के लिए सूची, वृक्ष आदि का चयन करना।
  3. कोई घटक और दृश्य घटक के बीच फ़्लिप करना।
• JInternalFrame/JDesktopPane आमतौर पर एमडीआई के लिए उपयोग किया जाता है ।
• JTabbedPane घटकों के समूहों के लिए।
• JSplitPane दो घटकों को प्रदर्शित करने का एक तरीका, जिसमें एक या दूसरे (आकार) के बीच का महत्व उपयोगकर्ता के अनुसार भिन्न होता है।
• JLayeredPane अब तक कई अच्छी तरह से .. घटक।
• JToolBarआमतौर पर कार्यों या नियंत्रणों के समूह होते हैं। जीयूआई के आसपास खींचा जा सकता है, या इसे पूरी तरह से उपयोगकर्ता की आवश्यकता के अनुसार बंद कर सकता है। जैसा कि ऊपर बताया गया है, ऐसा करने वाले माता-पिता के अनुसार कम से कम / बहाल करेगा।
• एक में आइटम JList(नीचे सरल उदाहरण)।
• के रूप में नोड्स में JTree।
• नेस्टेड लेआउट ।
  

लेकिन अगर वे रणनीतियाँ किसी विशेष उपयोग के मामले में काम नहीं करती हैं, तो निम्नलिखित प्रयास करें। एकल मुख्य की स्थापना करें JFrame, फिर बाकी फ़्लोटिंग तत्वों के लिए JDialogया JOptionPaneउदाहरण दिखाई देते हैं, संवाद के लिए मूल के रूप में फ्रेम का उपयोग करते हुए।

कई चित्र

इस मामले में जहां कई तत्व चित्र हैं, इसके बजाय निम्नलिखित में से किसी एक का उपयोग करना बेहतर होगा:

1. JLabelउपयोगकर्ता जो भी उस पल में रुचि रखता है प्रदर्शित करने के लिए एक एकल (एक स्क्रॉल फलक में केंद्रित)। जैसा देखा गया है ImageViewer।
   
2. एक एकल पंक्ति JList। जैसा कि इस उत्तर में देखा गया है । उस 'एकल पंक्ति' का हिस्सा केवल तभी काम करता है जब वे सभी समान आयाम हों। वैकल्पिक रूप से, यदि आप मक्खी पर छवियों को स्केल करने के लिए तैयार हैं, और वे सभी समान पहलू अनुपात (उदाहरण 4: 3 या 16, 9) हैं।

Comments

@AndrewThompson मैं कभी भी ऐसी स्थिति में नहीं आया था जहाँ मुझे JFrameपहले कई एस की आवश्यकता थी और उन मुद्दों पर कभी विचार नहीं किया, समझाने के लिए धन्यवाद!

— जेफरी

@ user417896 "बस निर्भर करता है।" नहीं, यह नहीं है। मैंने जिम्प का उपयोग किया है। यह भयानक है और एमडीआई होना चाहिए।

— एंड्रयू थॉम्पसन

@ryvantage "क्या (एक्सेल) MDI होना चाहिए?" अच्छा प्रश्न। मुझे लगता है कि यह दोनों तरीकों से उपयोगकर्ता को पेश किया जाना चाहिए (निश्चित रूप से न केवल एमडीआई रूप में)। उदाहरण के लिए: 1) मैं वर्तमान में टेक्स्टपैड का उपयोग करता हूं, और मेरी पसंद पर कॉन्फ़िगरेशन द्वारा, यह अलग-अलग उदाहरणों को खोलता है, कि प्रत्येक एक सूची में दिखाए गए कई दस्तावेज़ पेश करता है। 2) हालांकि मैं आमतौर पर टैब मोड में एफएफ का उपयोग करता हूं, कभी-कभी मैं टैब को एक नई विंडो पर खींचता हूं। - उदाहरणों में सामान्य कारक उपयोगकर्ता की पसंद है। एप्लिकेशन वितरित करें। 'हालांकि उपयोगकर्ता यह चाहता है'।

— एंड्रयू थॉम्पसन

@AndrewThompson आपने अपनी अंतिम टिप्पणी के साथ सिर्फ अपना तर्क दिया है। आपके मुख्य उत्तर में आप कहते हैं कि यह बुरा अभ्यास है और इसे कभी नहीं किया जाना चाहिए, लेकिन ऊपर की टिप्पणी में आप कहते हैं कि आप कभी-कभी एसडीआई पसंद करते हैं और हमें अपने उपयोगकर्ताओं की पसंद की पेशकश करनी चाहिए। निश्चित रूप से, यह वही है जो उपयोगकर्ता 417896 ऊपर कह रहा था। निर्भर करता है। यह मेरे साथी डेवलपर्स के बारे में मेरे सबसे बड़े पालतू जानवरों में से एक है। यह तथ्य कि उनमें से कई तथाकथित 'सर्वोत्तम प्रथाओं' के बारे में धार्मिक रूप से कट्टर हैं। हमारे पास आज के नवोन्मेषी UI नहीं हैं यदि हम सभी 'सर्वोत्तम प्रथाओं' से चिपके रहते हैं और वर्ग के बाहर नहीं सोचते हैं।

— डंकनकिनियर

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

— दाऊद इब्न करीम

Answer 2

JFrameजब से मैंने स्विंग ऐप्स की प्रोग्रामिंग शुरू की है, तब से कई दृष्टिकोण मेरे द्वारा लागू किए गए हैं। अधिकांश भाग के लिए, मैंने शुरुआत में ऐसा किया क्योंकि मुझे कोई बेहतर नहीं पता था। हालाँकि , जैसा कि मैंने एक डेवलपर के रूप में अपने अनुभव और ज्ञान में परिपक्व किया और जैसा कि ऑनलाइन और अधिक अनुभवी जावा देवों के विचारों को पढ़ना और अवशोषित करना शुरू किया, मैंने कई दृष्टिकोणों (वर्तमान परियोजनाओं और भविष्य की परियोजनाओं दोनों में) से दूर जाने का प्रयास किया JFrame) केवल साथ मिलने के लिए ... यह प्राप्त करें ... मेरे ग्राहकों से प्रतिरोध! जैसा कि मैंने "बच्चे" खिड़कियों को नियंत्रित करने और JInternalFrameअलग-अलग घटकों के लिए मोडल संवादों को लागू करना शुरू किया , मेरे ग्राहक शिकायत करने लगे!मैं काफी हैरान था, जैसा कि मैं सोच रहा था कि मैं सबसे अच्छा अभ्यास कर रहा हूं! लेकिन, जैसा कि वे कहते हैं, "एक खुश पत्नी एक खुशहाल जीवन है।" वही अपने ग्राहकों के लिए चला जाता है। बेशक, मैं एक ठेकेदार हूं, इसलिए मेरे एंड-यूजर्स की सीधी पहुंच मेरे पास है, डेवलपर, जो स्पष्ट रूप से एक सामान्य परिदृश्य नहीं है।

इसलिए, मैं कई JFrameदृष्टिकोणों के लाभों की व्याख्या करने जा रहा हूं , साथ ही कुछ अन्य द्वारा प्रस्तुत किए गए कुछ मिथक का भी पर्दाफाश करूंगा ।

1. लेआउट में अंतिम लचीलापन - अलग-अलग JFrameएस की अनुमति देकर , आप अपने अंतिम-उपयोगकर्ता को फैलाने और उसके स्क्रीन पर क्या है, इसे नियंत्रित करने की क्षमता देते हैं। अवधारणा "खुला" और गैर-संकुचित महसूस करती है। आप इसे खो देते हैं जब आप एक बड़े JFrameऔर एस के एक झुंड की ओर जाते हैं JInternalFrame।
2. बहुत ही संशोधित अनुप्रयोगों के लिए अच्छी तरह से काम करता है - मेरे मामले में, मेरे अधिकांश अनुप्रयोगों में 3 - 5 बड़े "मॉड्यूल" हैं जिनका वास्तव में एक-दूसरे के साथ कोई लेना-देना नहीं है। उदाहरण के लिए, एक मॉड्यूल एक सेल्स डैशबोर्ड हो सकता है और एक अकाउंटिंग डैशबोर्ड हो सकता है। वे एक दूसरे से या कुछ भी बात नहीं करते। हालाँकि, कार्यकारी दोनों को खोलना चाहता है और टास्कबार पर अलग फ्रेम होने से उसका जीवन आसान हो जाता है।
3. एंड-यूज़र्स के लिए बाहरी सामग्री को संदर्भित करना आसान बनाता है - एक बार, मेरे पास यह स्थिति थी: मेरे ऐप में एक "डेटा व्यूअर" था, जिसमें से आप "नया जोड़ें" पर क्लिक कर सकते थे और यह डेटा एंट्री स्क्रीन खोलेगा। शुरू में, दोनों JFrameएस थे । हालाँकि, मैं चाहता था कि डेटा एंट्री स्क्रीन एक JDialogअभिभावक हो, जो डेटा व्यूअर हो। मैंने परिवर्तन किया, और तुरंत मुझे एक अंतिम-उपयोगकर्ता से एक कॉल मिला, जो इस बात पर बहुत अधिक निर्भर था कि वह दर्शक को कम या बंद कर सकता है और संपादक को खुला रख सकता है, जबकि वह कार्यक्रम के दूसरे भाग (या वेबसाइट, मैं डॉन) का संदर्भ देता है। 'याद है)। वह मल्टी-मॉनिटर पर नहीं है , इसलिए उसे पहले और कुछ और के लिए प्रवेश संवाद की आवश्यकता थीदूसरा, डेटा व्यूअर के पूरी तरह से छिपे होने के साथ। यह एक के साथ असंभव था JDialogऔर निश्चित रूप से एक के JInternalFrameरूप में अच्छी तरह से असंभव हो गया होता । मैंने अपने संन्यासी के JFramesलिए अलग होने के कारण इसे बदल दिया , लेकिन इसने मुझे एक महत्वपूर्ण सबक सिखाया।
4. मिथक: हार्ड टू कोड - यह मेरे अनुभव में सच नहीं है। मैं यह नहीं देखता कि ए की JInternalFrameतुलना में बनाना आसान क्यों होगा JFrame। वास्तव में, मेरे अनुभव में, JInternalFramesबहुत कम लचीलापन प्रदान करते हैं। मैंने JFrameअपने ऐप्स में खुलने और बंद होने से निपटने का एक व्यवस्थित तरीका विकसित किया है जो वास्तव में अच्छा काम करता है। मैं फ्रेम के कोड के भीतर से लगभग पूरी तरह से फ्रेम को नियंत्रित करता हूं; नए फ्रेम का निर्माण, SwingWorkerजो पृष्ठभूमि थ्रेड्स पर डेटा की पुनर्प्राप्ति और ईडीटी पर जीयूआई कोड को नियंत्रित करता है, फ्रेम को सामने लाने / बहाल करने के लिए यदि उपयोगकर्ता इसे दो बार खोलने की कोशिश करता है, आदि। आप सभी को मेरा JFrameएस खोलने की आवश्यकता है। एक open()के साथ संयुक्त सार्वजनिक स्थैतिक विधि और खुली विधि को बुलाओwindowClosing() घटना बाकी को संभालती है (क्या फ्रेम पहले से ही खुला है? क्या यह खुला नहीं है, लेकिन लोड हो रहा है? आदि) मैंने इसे एक दृष्टिकोण बनाया है, इसलिए प्रत्येक फ्रेम के लिए इसे लागू करना मुश्किल नहीं है।
5. मिथक / अप्रमाणित: संसाधन भारी - मैं इस सट्टा कथन के पीछे कुछ तथ्य देखना चाहूंगा। हालाँकि, शायद, आप एक JFrameज़रूरत से ज़्यादा जगह की ज़रूरत कह सकते हैं JInternalFrame, भले ही आप 100 JFrameएस खोलते हों , आप वास्तव में कितने अधिक संसाधनों का उपभोग करेंगे? यदि आपकी चिंता संसाधनों की वजह से मेमोरी लीक है: dispose()कचरा संग्रह के लिए फ्रेम द्वारा उपयोग किए जाने वाले सभी संसाधनों को मुक्त करना (और, फिर से मैं कहता हूं, एक JInternalFrameबिल्कुल चिंता का विषय होना चाहिए)।

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

एकाधिक फ्रेम / फ्रेम प्रति एकल दस्तावेज़ ( SDI ) बनाम एकल फ्रेम / एकाधिक दस्तावेज़ प्रति फ्रेम ( MDI ) का एक बड़ा उदाहरण Microsoft Excel है। एमडीआई के कुछ लाभ:

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

SDI (एकल-दस्तावेज़ इंटरफ़ेस, अर्थात, प्रत्येक विंडो में केवल एक ही दस्तावेज़ हो सकता है):

MDI (एकाधिक-दस्तावेज़ इंटरफ़ेस, अर्थात, प्रत्येक विंडो में कई दस्तावेज़ हो सकते हैं):

Comments

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

— जेफरी

बहुत अच्छा जवाब और विस्तृत उत्तर हालांकि मुझे इस पर @kleopatra से सहमत होना है .. मेरे पास एक बार एक सौ से अधिक स्क्रीन के साथ एक एप्लिकेशन था जहां उपयोगकर्ता विभिन्न इनपुट के साथ कई स्क्रीन / एक ही स्क्रीन से आउटपुट डेटा की तुलना करना चाहते थे। हमने एक कस्टम विंडोिंग सिस्टम बनाया है जिससे हम ऐसा कर सकें। 2 JFrames को एक-दूसरे के पास रखने के लिए उपयोगकर्ता केवल अधिक आरामदायक थे;)

— javatarz

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

— गुयिल्यूम पॉलेट

मैं सहमत हूँ कि sdi कभी-कभी उचित होता है (और उपयोगकर्ता अक्सर इसे पसंद करते हैं)। एक और कमी है, और मुझे उसके लिए अब तक कोई वर्कअराउंड नहीं मिला, दुर्भाग्यपूर्ण: प्रत्येक JFrameको अपना स्वयं का कार्य आइकन मिलता है। कभी-कभी यह वही होता है जो आप चाहते हैं, लेकिन कभी-कभी यह नहीं होता है। WinAPI में यह कॉन्फ़िगर करना आसान है, लेकिन स्विंग में ऐसा लगता है कि यह नहीं किया जा सकता है।

— सुमा

@ उस मामले में मुझे लगता है कि मैं एक JDialogओवर के लिए विकल्प चुनूंगा JFrame।

— 1927 में

Answer 3

मैं एक उदाहरण के साथ "उपयोगकर्ता के अनुकूल नहीं" तर्क का मुकाबला करना चाहता हूं जो कि मैं अभी भी शामिल हूं।

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

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

कुछ महीने पहले हमें अपने ग्राहकों से इन रिपोर्ट व्यूअर विंडो को मॉडल बनाने के लिए अनुरोध मिलना शुरू हुआ, ताकि वे एक ही समय में कई रिपोर्ट खोल सकें।

कुछ समय के लिए मैंने इस अनुरोध का विरोध किया क्योंकि मुझे नहीं लगा कि यह एक अच्छा समाधान था। हालाँकि, मेरे दिमाग में बदलाव आया जब मुझे पता चला कि हमारे सिस्टम की इस 'कमी' के बारे में उपयोगकर्ताओं को कैसे पता चल रहा है।

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

इसलिए मैंने भरोसा किया और दर्शक को आदर्श बनाया। इसका मतलब है कि प्रत्येक दर्शक के पास एक टास्क-बार आइकन है।

जब पिछले सप्ताह उन्हें नवीनतम संस्करण जारी किया गया था, तो उनकी ओर से भारी प्रतिक्रिया यह है कि उन्होंने इसे पसंद किया। यह सिस्टम के लिए हमारे सबसे लोकप्रिय हाल के एन्हांसमेंट्स में से एक रहा है।

इसलिए आप आगे बढ़ें और अपने उपयोगकर्ताओं को बताएं कि वे जो चाहते हैं वह बुरा है, लेकिन अंततः यह आपको कोई एहसान नहीं करेगा।

कुछ नोट:

• JDialog का उपयोग इन मॉडल विंडो के लिए करना सबसे अच्छा अभ्यास लगता है
• ModalityTypeबूलियन modalतर्क के बजाय नए का उपयोग करने वाले निर्माणकर्ताओं का उपयोग करें । यह वही है जो इन संवादों को कार्य-बार आइकन देता है।
• मॉडल के संवादों के लिए, एक अशक्त माता-पिता को निर्माता के पास भेज दें, लेकिन उन्हें उनकी 'मूल' विंडो के सापेक्ष खोजें।
• विंडोज पर जावा के संस्करण 6 में एक बग है जिसका अर्थ है कि आपकी मुख्य विंडो बिना बताए 'हमेशा शीर्ष पर' बन सकती है। इसे ठीक करने के लिए संस्करण 7 में अपग्रेड करें

Comments

यह वास्तव में मेरा अनुभव भी है। अगर कोई एक चीज है जो मैं निश्चित हूं, तो यह है कि आप कुछ गलत कर रहे हैं जब लोग कोशिश करते हैं और अपनी उपयोगकर्ता-अनुकूलता को दरकिनार करते हैं, जो कुछ भी वे वास्तव में करना चाहते हैं। कार्यक्षमता राजा है।

— ryvantage

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

— ग्विल्यूम पॉलेट

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

— डंकनकिनियर

@GuillaumePolet मैं डंकन से सहमत हूं, क्या आप समझा सकते हैं कि आपका मतलब क्या है? मैं उनके भ्रम को साझा करता हूं

— Ungeheuer

मुझे लगता है कि उसका क्या मतलब है कि उपयोगकर्ता एप्लिकेशन ('JFrame') की कई प्रतियां शुरू कर सकता है, लेकिन उनमें से प्रत्येक के अंदर यह एसडीआई है। हालांकि, हमारा क्लाइंट एप्लिकेशन बहुत मोटा क्लाइंट है, इसलिए यह एक संसाधन भूख दृष्टिकोण होगा।

— डंकनकिनियर

Answer 4

मुख्य फ्रेम में एक JInternalFrame बनाएं और इसे अदृश्य बनाएं। फिर आप इसे आगे की घटनाओं के लिए उपयोग कर सकते हैं।

jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);

Answer 5

पिछली बार जब मैं स्विंग को छूता था तब से कुछ समय हो गया है लेकिन सामान्य तौर पर ऐसा करना एक बुरा अभ्यास है। कुछ मुख्य नुकसान जो दिमाग में आते हैं:

• यह अधिक महंगा है: आपको JFrame को आकर्षित करने के लिए अधिक संसाधनों को आवंटित करना होगा जो कि अन्य प्रकार के विंडो कंटेनर, जैसे कि Dialog या JInternalFrame।

• उपयोगकर्ता के अनुकूल नहीं: एक साथ अटके हुए JFrame के एक झुंड में नेविगेट करना आसान नहीं है, ऐसा लगेगा कि आपका आवेदन असंगत और खराब डिज़ाइन के अनुप्रयोगों का एक सेट है।

• JInternalFrame का उपयोग करना आसान है। यह एक तरह से रेटोरिअल है, अब यह आसान है और अन्य लोग (या अधिक खाली समय के साथ) हम से पहले ही डेस्कटॉप और JInternalFrame पैटर्न के माध्यम से सोच चुके हैं, इसलिए मैं इसका उपयोग करने की सलाह दूंगा।

Comments

जब आप एकाधिक का उपयोग कर रहे हैं, तो क्या आपके पास उपयोगकर्ता के लिए समान प्रभाव नहीं JInternalFrameहै? व्यक्तिगत रूप से, मैं के उपयोग से असहमत हूँ JInternalFrame! CardLayoutएक असली आशीर्वाद है!

— ब्रिसिल्लव लाजिक

मैं @ brano88 से सहमत हूं। JInternalFrameआपके द्वारा बताए गए तीन मामलों में से किसी में भी कोई लाभ नहीं है। (1. सबूत कहां JInternalFrameसे हल्का है JFrame? 2. आपका JInternalFrames सिर्फ गुच्छेदार / गन्दा हो सकता है / एक साथ JFrames की एक गुच्छा के रूप में अटक सकता है । 3. JInternalFrameयह कितना आसान है? एक ही सटीक कोड, एक को छोड़कर एक के भीतर समाहित है JDesktopPaneऔर एक प्राकृतिक स्क्रीन क्षेत्र के भीतर समाहित है। वे मेरे लिए समान रूप से जटिल लगते हैं।)

— ryvantage

1. JFrame JInternalFrame की तुलना में एक हेवीवेट घटक है जो हल्का है। 2. क्या आपने कभी ऐसा ऐप देखा है जिसमें कार्यात्मक होने के लिए एक ही समय में टन की खिड़कियां हों? आईडीई, ब्राउजर, यहां तक ​​कि वित्त अनुप्रयोग में भी इसे उसी दायरे में रखने का लक्ष्य है। 3. मैंने पाया है कि JIF को अतीत में उपयोग करना बहुत आसान है और इस बात की कोई शिकायत नहीं है कि उस घटक को चुना जाए जो एक परिदृश्य के लिए सबसे उपयुक्त हो

— नेक्रोनैट

1. मैं इसका प्रमाण देखना चाहूंगा। दोनों वस्तुएं हैं, दोनों JComponentएस हैं, दोनों में लगभग समान संरचनाएं हैं, सिवाय एक पर एक JDesktopऔर प्रदान नहीं किया गया है। फिर से, क्षमा करें, लेकिन मेरा मानना ​​है कि आप "वजन" के बारे में अनुमान लगा रहे हैं JFrame। 2. मेरे अनुप्रयोग sdi का उपयोग करते हैं और मेरे ग्राहक बहुत खुश हैं। हालांकि, आपने कहा "एक टन की खिड़कियां,", जो निश्चित रूप से चूसना होगा। लेकिन, मेरी बात यह है: "एक टन का JInternalFrameसिर्फ इतना बुरा चूसना होगा! यदि आप कह रहे हैं कि JIF आपको एक मैला यूआई डिजाइनर होने की अनुमति देता है, तो यह भयानक है। एक अव्यवस्थित गड़बड़ एक बरबाद गंदगी है, चाहे JF या JIF।

— अत्याचार

"बेशक उस घटक को चुनें जो सबसे अच्छा एक परिदृश्य को सूट करता है"

— नेक्रॉनट

Answer 6

बुरा अभ्यास जरूर करें। एक कारण यह है कि यह इस तथ्य के लिए बहुत 'उपयोगकर्ता के अनुकूल' नहीं है कि हर JFrameएक नया टास्कबार आइकन दिखाता है। कई JFrameएस को नियंत्रित करने से आपको अपने बालों को बाहर निकालना होगा।

व्यक्तिगत रूप से, मैं JFrameआपके आवेदन के लिए वन का उपयोग करूंगा । कई चीजों को प्रदर्शित करने के तरीके आपके ऊपर हैं, कई हैं। Canvases, JInternalFrame, CardLayout, यहां तक कि JPanelसंभवतः है।

एकाधिक JFrame ऑब्जेक्ट्स = दर्द, परेशानी और समस्याएं।

Comments

हम्म ... स्वीकार किए जाते हैं जवाब, afaics की तुलना में नया कुछ भी नहीं?

— क्लेओपेट्रा

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

— रॉल्फ

Answer 7

मुझे लगता है कि कई Jframeएस का उपयोग करना एक अच्छा विचार नहीं है।

इसके बजाय हम उपयोग कर सकते हैं JPanelरों की तुलना में अधिक एक या अधिक JPanelएक ही में JFrame।

इसके अलावा, हम इस JPanelएस के बीच स्विच कर सकते हैं । तो यह हमें चीज़ में से अधिक प्रदर्शित करने की स्वतंत्रता देता है JFrame।

प्रत्येक के लिए JPanelहम विभिन्न चीजों को डिजाइन कर सकते हैं और यह सब एक बार में एक JPanelपर प्रदर्शित किया जा सकता है JFrame।

प्रत्येक या 'JButton JPanel` के लिए इस JPanelउपयोग के बीच स्विच करने JMenuBarके JMenuItemsलिए ।JPanelfor each

एक से अधिक JFrameएक अच्छा अभ्यास नहीं है, लेकिन अगर हम एक से अधिक चाहते हैं तो कुछ भी गलत नहीं है JFrame।

लेकिन इसकी बेहतर है कि JFrameहम अपनी अलग-अलग जरूरतों के लिए एक से ज्यादा JFrameएस करें।

Answer 8

यदि फ़्रेम एक ही आकार के होने जा रहे हैं, तो फ़्रेम क्यों न बनाएं और फ़्रेम को पास करें, इसके बजाय इसके संदर्भ के रूप में।

जब आप फ्रेम पास कर लेते हैं तो आप यह तय कर सकते हैं कि इसे कैसे पॉप्युलेट किया जाए। यह आंकड़ों के एक सेट के औसत की गणना के लिए एक विधि होने जैसा होगा। क्या आप बार-बार विधि का निर्माण करेंगे?

Comments

यह मूल रूप से कार्डलेआउट और JTabbedPane कर सकता है, लेकिन एक ही चीज़ को प्राप्त करने के लिए आपके पास स्वच्छ और आसान समाधान होने पर इसे उल्टा करना और अपने कोड को अत्यधिक जटिल बनाना है।

— गुयिल्यूम पॉलेट

Answer 9

यह एक अच्छा अभ्यास नहीं है, लेकिन भले ही आप इसका उपयोग करना चाहते हैं, लेकिन आप सिंगलटन पैटर्न को इसके अच्छे के रूप में उपयोग कर सकते हैं। मैंने अपने ज्यादातर प्रोजेक्ट में सिंगलटन पैटर्न का इस्तेमाल किया है।

Comments

सिंगलटन पैटर्न एक बुरा सपना है। कोई भी परियोजना जो स्केल करना चाहती है उसे हर कीमत पर सिंगलटन पैटर्न से बचने की कोशिश करनी चाहिए।

— गिलाउम पोइल