11

in my app I disabled the keyboard (I use now my custom keyboard) using this code:

editText.setInputType(InputType.TYPE_NULL);

Now, my problem is that the text cursor does not appear anymore in the edit text. What should I do? Any suggestion would be very appreciated.

General Grievance
  • 4,555
  • 31
  • 31
  • 45
Laura
  • 2,653
  • 7
  • 37
  • 59
  • it doesn't appear because there is no keyboard, hence no reason to have a cursor – njzk2 Jan 11 '13 at 17:04
  • But I use my custom keyboard and I want the cursor to be visible. How can I do that? – Laura Jan 11 '13 at 17:09
  • are letters visible? I faced an issue in which due to theme everything has the color of the background and seems invisible changing the foreground or the background color may help. Pay attention to hint and cache colors too! – madlymad Feb 12 '13 at 08:53

4 Answers4

23

There is an Issue opened in bug tracker Issue opened in bug tracker for this. One of the users suggests the approach which works on "most" devices.

Briefly, all you have to do is call:

editText.setRawInputType(InputType.TYPE_CLASS_TEXT);

for your EditText view (after you called editText.setInputType(InputType.TYPE_NULL);).

You should probably also set:

editText.setTextIsSelectable(true);

in order for text to be selectable (though in does not seem to work properly with Samsung Galaxy SIII). This method is only available starting from HONEYCOMB (api11) so keep that in mind when developing for older Android versions.

Also it is stated that your EditText should not be the first view to receive focus when activity starts (if it is - just requestFocus() from another view). Though I (personally) have not experienced any problems with this.

Alex Semeniuk
  • 1,865
  • 19
  • 28
  • Thanks a lot for your answer. I have tried something similar before but it didn't work. I guess it was because I didn't set my edit text to setTextIsSelectable(true); – Laura Feb 12 '13 at 12:17
  • I would note that this problem apparently does not occur prior to API 15 or so (based on reports and my own testing) and so setTextIsSelectable() *should* be available for all devices exhibiting the problem. You will have to test the API (or use reflection to test for the method) to ensure that the method is available on a device if you support APIs that pre-date the method. ALSO, FYI, I have tried editText.setRawInputType() by itself with an APK targeted to API level 9 and it has not resolved the problem. This may mean that, as ziziana has also suggested, both methods are required – Carl Nov 06 '13 at 12:20
  • It works for me. It would be good if any explanation is given on why this solution works. thanks. – Sandeep R Jan 16 '17 at 08:45
  • Alternative in the xml you can also give it as `android:textIsSelectable=true` – JaydeepW Feb 15 '20 at 15:06
0

Rather than just using a custom view for your custom keyboard, why not implement a full-fledged IME? That will solve your cursor problem, and even make your keyboard available outside your app (if you want).

This answer has a couple useful links if you want to do that: How to develop a soft keyboard for Android?

Community
  • 1
  • 1
dokkaebi
  • 9,004
  • 3
  • 42
  • 60
  • Full-fledged IME has 2 major restrictions: – Alex Semeniuk Feb 13 '13 at 09:51
  • 1) You should ask user permission to install the additional IME. 2) User should explicitly state that he wants to use your custom IME instead of standard IME (which involves tweakink device settings). Obviously this does not fit the situation where user only wants to restrict input in one particular EditText field – Alex Semeniuk Feb 13 '13 at 10:09
0

I really wouldn't suggest this. Writing a good full fledged IME is really hard. In addition, users come to expect functionality from their keyboard (auto-correct, Swyping, next word prediction, the ability to change languages) that you won't have unless you spend months on the keyboard itself. Any app that wouldn't allow me to use Swype would immediately be removed (bias note: I worked on Swype android).

But if you want to integrate fully with the OS as a keyboard, you're going to have to write an InputMethodService. Your keyboard would then be selectable by the user in the keyboard select menu, and usable for any app. That's the only way to get full OS integration, otherwise you'll need to really start from scratch- writing your own EditView. Have fun with that, getting one that looks nice is decidedly non-trivial.

Also, setting input type null won't disable most keyboards. It just puts them into dumb mode and turns off things like prediction.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127
  • 1
    Obviously the current discussion is not related to creating your own Input Method which will utilise every possible use-case. What people want to do is to just limit user input to some pre-defined variants (custom letters, symbols or phrases) So the developer should know better when it is a good idea to disable standard input or not. – Alex Semeniuk Feb 13 '13 at 09:49
  • A dev has the right to do so, but I would still heavily discourage it. I wouldn't use any app that didn't allow me to use a keyboard with Swype capability. In general replacing the keyboard on a user is a bad idea. – Gabe Sechan Feb 13 '13 at 15:07
  • Actually it does-I tell them how to write a actual Android keyboard and why their approach is fundamentally flawed – Gabe Sechan Dec 15 '15 at 00:37
0

I tried the below answer and it worked, but take care that 1) EditText must not be focused on initialization 2) when your orientation changes while the user's focus is on the editText, the stock keyboard pops up, which is another "solvable" problem.

This was mentioned in a previous answer but take care that you MUST make sure your editText element do not get focus on instantiation:

https://code.google.com/p/android/issues/detail?id=27609#c7

#7 nyphb...@gmail.com

I have finally found a (for me) working solution to this.

First part (in onCreate):

mText.setInputType(InputType.TYPE_NULL);
if (android.os.Build.VERSION.SDK_INT >= 11 /*android.os.Build.VERSION_CODES.HONEYCOMB*/) {
    // this fakes the TextView (which actually handles cursor drawing)
    // into drawing the cursor even though you've disabled soft input
    // with TYPE_NULL
    mText.setRawInputType(InputType.TYPE_CLASS_TEXT);
}

In addition, android:textIsSelectable needs to be set to true (or set in onCreate) and the EditText must not be focused on initialization. If your EditText is the first focusable View (which it was in my case), you can work around this by putting this just above it:

<LinearLayout
  android:layout_width="0px"
  android:layout_height="0px"
  android:focusable="true"
  android:focusableInTouchMode="true" >
    <requestFocus />
</LinearLayout>
KaBoZ
  • 41
  • 6