Android requestFocus() 的问题

发布于 2024-09-26 19:39:50 字数 683 浏览 1 评论 0原文

下面是我编写的用于将焦点从一个编辑文本转移到另一个编辑文本的代码,但我在这个实现中遇到的问题是,焦点移动到特定的编辑文本,然后突然移动到下一个编辑文本.所以,我无法输入任何内容,因为焦点根本不停留在特定的编辑文本上..

//some code comes here
// gun_pistolNotes and gun_pistolModel are two diff. editText
......
......
    gun_pistolNotes.setOnEditorActionListener(new OnEditorActionListener(){
    @Override
    public boolean onEditorAction(TextView view,int actionId, KeyEvent event){
    if(actionId == EditorInfo.IME_ACTION_UNSPECIFIED){
        gun_pistolModel.requestFocus(); // moves to this edittext and suddenly moves to another editext 
        return true;
    }
    return false;
    }
  });

......
......
//some code comes here

感谢任何帮助。

提前致谢。

The below is the piece of code that i have written for transferring the focus from one edit text to another, but the problem that i got with this implementation is, the focus moves to the particular edit text, and suddenly moves to the next edit text.So, i could not able to enter anything , since the focus is not at all staying that particular edit text ..

//some code comes here
// gun_pistolNotes and gun_pistolModel are two diff. editText
......
......
    gun_pistolNotes.setOnEditorActionListener(new OnEditorActionListener(){
    @Override
    public boolean onEditorAction(TextView view,int actionId, KeyEvent event){
    if(actionId == EditorInfo.IME_ACTION_UNSPECIFIED){
        gun_pistolModel.requestFocus(); // moves to this edittext and suddenly moves to another editext 
        return true;
    }
    return false;
    }
  });

......
......
//some code comes here

Any Help is Appreciated.

Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

半山落雨半山空 2024-10-03 19:39:50

我意识到这是一个老问题,但我面临着类似的问题&经过几个小时的沮丧后,我发现了这个问题,所以我想我应该将其发布在这里,以防其他人需要它。

在我的代码中,我意识到由于某种原因在我的编辑文本上指定 android:inputype 导致了这种“跳跃”行为。因此,如果我在 XML 中有 EditText1android:inputType="textCapSentences",则在 EditText1requestFocus() > 使其在将焦点移至下一个视图之前短暂突出显示。

我不确定这是否是 Android 中的一个错误,或者是否确实是我遗漏的其他内容。我尝试以编程方式设置 inputType在我的代码中的各个点内,使用 setInputType() 但它对我不起作用。所以现在我刚刚删除了 inputType 属性 & requestFocus() 正常工作。

I realise this is an old question, but I was facing a similar issue & after hours of frustration, I found the problem, so just thought I should post it here in case someone else needs it.

In my code I realised that for some reason specifying android:inputype on my edittext was causing this "jumping" behaviour. So if I have EditText1 with android:inputType="textCapSentences" in the XML, calling requestFocus() on EditText1 causes it to get highlighted briefly before moving focus onto the next view.

I am not sure if this is a bug within Android or if it is indeed something else that I am missing. I tried setting inputType programmatically & within various points in my code, with setInputType() but it did not work for me. So for now I have just removed the inputType attribute & requestFocus() works as it should.

一笑百媚生 2024-10-03 19:39:50

我面临着完全相同的问题。我可以确认 Kre8 的声明,即只有设置了特定的输入类型(在我的例子中为 textNoSuggestion / singleLine)时才会发生此行为。稍后我将解释为什么会出现这种情况。

我决定分析视图内部发生了什么。毕竟我可以说这不是一个错误,也许只是一个不快乐的星座:)。您请求焦点的 EditText 正确接收了焦点。

您的第一个可能无法识别的问题是 EditorActionListener 被调用两次。一次为向上键,一次为向下键。我不知道您检查 actionId 的效果,因此也许可以防止您的代码被执行两次。

所以我在解决方案请求中错误地调用了关注 ACTION_DOWN 键事件。 EditText 正确接收到焦点,但是在即将到来的 ACTION_UP 事件(该事件由新聚焦的 EditText 以某种方式解释)上,焦点立即发送回先前发送焦点的 EditText,因为它在下一个接收的焦点搜索中。

所以我想现在输入类型会产生影响,因为如果 EditText 处于多行模式,则 Enter 键将不会进一步发送焦点。

我的最终工作解决方案如下所示:

passwordEditText.setOnEditorActionListener(new OnEditorActionListener() {

  @Override
  public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
    if (event != null && event.getKeyCode() == KeyEvent.KEYCODE_ENTER && v == passwordEditText) {
      if (event.getAction() == KeyEvent.ACTION_UP) {
        if (userEditText.length() > 0 && passwordEditText.length() > 0) {
          login();
        }
        if (userEditText.length() == 0) {
          userEditText.requestFocus();
        }
      }
      return true;
    }
    return false;
  }
});

希望它也适合您:)

编辑:我忘了指出,可以根据需要选择 EditText 的输入类型,因为 onEditorAction 方法可以处理向上和向下两种情况。

I am facing exactly the same problem. I can confirm Kre8's statement that this behaviour only occurs if there's set a specific input type (in my case textNoSuggestion / singleLine). I'll explain later why this probably is the case.

I decided to analyse what's going on inside the View. After all i can say it is not a bug just an unhappy constellation maybe :). The EditText for which you requested focus, correctly receives it.

Your first maybe unrecognized problem is, that the EditorActionListener is called twice. Once for key up and once for down. I don't know the effect of your check of the actionId, so that maybe preservers your code from being executed twice.

So i called wrongly in my solution request focus on ACTION_DOWN key event. The EditText received focus correctly, BUT on the coming ACTION_UP event, which is somehow interpreted by the newly focused EditText, focus was sent immediatly back to the previously sending focus EditText because it is in the focus search the next receiving.

So i guess now the input type has an effect because, if the EditText is in a multiline mode, the enter key will not send focus further.

My final working solution looks like that:

passwordEditText.setOnEditorActionListener(new OnEditorActionListener() {

  @Override
  public boolean onEditorAction(TextView v, int actionId, KeyEvent event) {
    if (event != null && event.getKeyCode() == KeyEvent.KEYCODE_ENTER && v == passwordEditText) {
      if (event.getAction() == KeyEvent.ACTION_UP) {
        if (userEditText.length() > 0 && passwordEditText.length() > 0) {
          login();
        }
        if (userEditText.length() == 0) {
          userEditText.requestFocus();
        }
      }
      return true;
    }
    return false;
  }
});

Hope it works for you as well :)

Edit: I forgot to point out, that the input type of the EditText can be choosen as you want, because the onEditorAction method handles both, up and down.

硬不硬你别怂 2024-10-03 19:39:50

我发现这工作可靠:

        field1Text.setOnEditorActionListener(new TextView.OnEditorActionListener() {
        @Override
        public boolean onEditorAction(TextView textView, int i, KeyEvent keyEvent) {
            if ((i == EditorInfo.IME_ACTION_UNSPECIFIED) && (keyEvent != null) &&
                    (keyEvent.getKeyCode() == KeyEvent.KEYCODE_ENTER)) {
                if (keyEvent.getAction() == KeyEvent.ACTION_DOWN) {
                    return true;
                }
                i = EditorInfo.IME_ACTION_DONE;
            }
            if (i == EditorInfo.IME_ACTION_DONE) {
                field2Text.requestFocus();
                return true;
            }
            return false;
        }
    });

这可以处理键盘输入和单击虚拟键盘中的操作按钮。奇怪的逻辑失败是因为我在 requestFocus 分支上做了一些其他事情,我在这里省略了这些事情,因为它们不是问题的一部分。

I found this worked reliably:

        field1Text.setOnEditorActionListener(new TextView.OnEditorActionListener() {
        @Override
        public boolean onEditorAction(TextView textView, int i, KeyEvent keyEvent) {
            if ((i == EditorInfo.IME_ACTION_UNSPECIFIED) && (keyEvent != null) &&
                    (keyEvent.getKeyCode() == KeyEvent.KEYCODE_ENTER)) {
                if (keyEvent.getAction() == KeyEvent.ACTION_DOWN) {
                    return true;
                }
                i = EditorInfo.IME_ACTION_DONE;
            }
            if (i == EditorInfo.IME_ACTION_DONE) {
                field2Text.requestFocus();
                return true;
            }
            return false;
        }
    });

This handles both keyboard enter and clicking on the action button in the virtual keyboard. The odd fall through logic is because I do some other things the requestFocus branch, which I omitted here because they're not part of the issue.

凡间太子 2024-10-03 19:39:50

Android 始终内置支持将“上/下/右/左”层次结构编码为视图。这最初是为 G1 等轨迹球设备完成的。我认为您没有发现错误 - 但我们可以通过查看一些 SDK 源代码进行验证。对于面临类似问题的人,您可以尝试在需要“模糊”的视图上调用 setNext**Focus(...) ,然后生成一个事件以移动到“下一个字段”。这既可以在 XML 中完成,也可以在运行时完成。你们尝试过这个吗?

请参阅 View#focusSearch(int) 和 View#setNext**Focus(int)。 SDK 建议您在 onEditorAction(...) 中编写如下内容:

...
if (userEditText.length() == 0) {
hostGameBtn.setNextFocusDownId(R.id.myUserEditTextViewID);
hostGameBtn.focusSearch(View.FOCUS_DOWN);
}
...

Android has always had builtin support for coding an "up/down/right/left" hierarchy to views. This was done originally for trackball devices like the G1. I don't think you've found a bug - but we could verify by looking at some SDK source. For people facing a similar problem, you might try calling setNext**Focus(...) on the View that needs to be "blurred", and then generating an event to move to the "next field down". This can be done both in XML and during runtime. Have you guys tried this?

See View#focusSearch(int) and View#setNext**Focus(int). The SDK suggests that in your onEditorAction(...) you could write something like:

...
if (userEditText.length() == 0) {
hostGameBtn.setNextFocusDownId(R.id.myUserEditTextViewID);
hostGameBtn.focusSearch(View.FOCUS_DOWN);
}
...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文