I'm not hurt by you choosing to go a different path. Just seems like you are leaving a lot on the table that's already written for you by trying to put a square peg into a round hole. I checked out that project and I think you are cutting yourself short here because of the following:
1. Now you have to write a full select/copy/paste routine since you've overridden it by catching the long click 2. You don't give a defined space so the user understands the bounds of the view 3. Touching to place the cursor somewhere causes it to keep editing and leaves the cursor there, but dismiss the keyboard I only tested it a little, so I'm not sure what other issues might pop up as you use it more. You may also want to find a place for android:imeOptions="flagNoExtractUi" (or similar in code) so that it doesn't popup the full UI of the keyboard in landscape mode so it still feels like you are editing in place. And a android:configChanges="orientation|keyboardHidden" on your activity because it resets your views on rotate otherwise. It seems like you are actually causing more work for yourself, but if it's working like you want it to, then that's what matters. Steven Studio LFP http://www.studio-lfp.com On Friday, October 7, 2011 1:48:57 PM UTC-5, Raffaele Sgarro wrote: > > Here is the whole Eclipse > project<http://www.2shared.com/file/us3MXMdS/custom-edit-text.html?> > > After more than 6 hours working on this, I finally found a solution. It's > simpler than what I thought. > The key point is using setFocusable()and setFocusableInTouchMode() at the > right moments, and manually showing and hiding the soft keyboard. I hope you > download the sample and execute it, so I can have a reasonable feedback. > > There is also a little onKeyPreIme() invocation which causes the custom > view to clear its state when the user manually hides the soft keyboard by > pressing the return key. > > Thanks to all of you > > 2011/10/7 Raffaele Sgarro <[email protected]> > >> Sorry Steven, I didn't mean to hurt you >> I appreciate your help a lot, you are the only one which actually coded >> something, and I believe this is very valuable. The layout approach was my >> first attempt, but I'm working on something cleaner and I think I have >> finally found a solution, which I'll post here so someone can test it and >> see if it works as expected. >> >> >> 2011/10/7 Studio LFP <[email protected]> >> >>> etNew.requestFocus(); >>> InputMethodManager mgr = (InputMethodManager) >>> context.getSystemService(Context.INPUT_METHOD_SERVICE); >>> mgr.showSoftInput( etNew, InputMethodManager.SHOW_IMPLICIT ); >>> >>> There, add that to the case: TYPE_EDIT before the break and your done. >>> And yes, there is a reason to make your own. It's easier, faster and is >>> more >>> configurable because you can control every detail. >>> >>> Ignore help if you want, but I don't think anyone here is going to write >>> all the details for you. We are here to point people in the right >>> direction >>> and for them to fill in the details. There are still details that are >>> needed >>> to make that fully functional, but they are easy because you have infinite >>> control in your own class. >>> >>> >>> Steven >>> Studio LFP >>> http://www.studio-lfp.com >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Developers" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/android-developers?hl=en >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
