2011-05-15 15 views
8

मेरे पास एक सामान्य संपादन टेक्स्ट है। यह बहुत अजीब है क्योंकि हार्ड कीबोर्ड का उपयोग करते समय मैं इसे फोकस नहीं कर सकता। प्रसंग हालत: परहार्ड कीबोर्ड संपादित करने में विफलता टेक्स्ट

  1. स्विच Droid के hardkeyboard गतिविधि
  2. शुरू
  3. इनपुट के लिए इनपुट
  4. विफल editText क्लिक करें। जब आप कोई भी कुंजी दबाते हैं, तो संपादन टेक्स्ट फोकस खो देता है।

फोकस पाने के लिए: प्रेस Dpad और आप ध्यान केंद्रित स्क्रीन में 1 विजेट से शुरू होता है देखेंगे। और अंत में लक्ष्य EditText पर ध्यान केंद्रित करें। फिर आप इनपुट कर सकते हैं। इसके बिना, आप हार्ड कीबोर्ड के साथ इनपुट नहीं कर सकते हैं।

सॉफ़्ट कीबोर्ड में ऐसी फ़ोकस समस्या नहीं है।

मैं एंड्रॉइड 2.2 का उपयोग कर रहा हूं। क्या यह एक सिस्टम बग है?

+0

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

+0

मुझे लगता है कि एडिटटेक्स्ट किसी और चीज से लपेटा जा सकता है और फिर यह टूट गया है। एक समान स्थिति स्क्रॉलबार में एक सूची दृश्य लपेटती है। मैं एक संपादन पाठ का उपयोग करने की कोशिश करता हूं और यह ठीक है। मैं आपके द्वारा प्रदान की जाने वाली जानकारी के साथ लेआउट की जांच करूंगा और बाद में टिप्पणी करूंगा। –

+0

मुझे अभी भी इसके लिए कोई समाधान नहीं मिल रहा है।मुझे बस इतना मिल सकता है: जहां एडिटटेक्स्ट हार्ड कीबोर्ड फोकस हासिल करने में विफल रहता है वहां शीर्ष पर एक टैबहोस्ट होता है। इसके बारे में कोई विचार? –

उत्तर

0

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

एक परिवर्तन मैंने अपने संपादन टेक्स्ट में किया था इनपुट इनपुट को पूरी तरह से दशमलव के रूप में बदलना है। तो जब संपादन टेक्स्ट फोकस प्राप्त करता है, तो सॉफ्ट कीबोर्ड एक संख्यात्मक कुंजी-पैड दिखाता है, न कि वर्णमाला क्वर्टी कुंजी-पैड। मैंने इसे मोटोरला Droid प्रो एमुलेटर पर चलाया, जिसे मैंने मोटोडेस वेबसाइट से एक्लिप्स प्लगइन्स में अपडेट किया। जाहिर है, जब मैं संपादन टेक्स्ट (और सॉफ्ट-कीबोर्ड एक संख्यात्मक कुंजी-पैड दिखा रहा है) के लिए फोकस देने के बाद हार्ड कीबोर्ड से पाठ दर्ज करने का प्रयास करता हूं, तो मैं 'ALT + 2' पर क्लिक करने के बाद, सॉफ्ट-कीबोर्ड पुनः लोड किया जाता है वर्णमाला कुंजी-पैड के रूप में, जबकि पाठ पाठ पूरी तरह से ध्यान केंद्रित करता है।

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

9

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

@Override 

public boolean onKeyDown(int keyCode, KeyEvent event){ 

    final EditText myInputField = (EditText) findViewById(R.id.MyInputEditText); 
    // this will happen on first key pressed on hard-keyboard only. Once myInputField 
    // gets the focus again, it will automatically receive further key presses. 
    if (!myInputField.hasFocus()){ 
     myInputField.requestFocus(); 
     myInputField.onKeyDown(keyCode, event); 
    } 
    return super.onKeyDown(keyCode, event); 
} 

यदि आप कई EditText क्षेत्रों है, तो आप ट्रैक रखने के लिए के वर्तमान में एक वर्ग चर में EditText ध्यान केंद्रित OnKeyDown पद्धति में उपयोग की आवश्यकता होगी।

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