问题描述
我用一些自定义ActionModes在我的应用程序。当操作模式是封闭的，我做一些家务，如关闭相关意见，更新的变化，等等。我发现动作模式在OnDestroyActionMode被关闭。
I use some custom ActionModes in my application. When an action mode is closed, I do some housekeeping, like closing related views, updating changes, etc.. I detect the action mode has been closed in OnDestroyActionMode.
我的问题是，当我的一些ActionModes内，用户可能会引发另一个系统actionmode（文本复制/粘贴/选择）。在这种情况下，onDestroyActionMode叫我错误地asume用户与第一actionmode完成，而不是实现一个堆栈的功能，这样我就可以忽略这个onDestroyActionMode，让用户编辑/剪切/等文本，然后重新打开完成后的前actionmode。
My problem is, when inside of some of my ActionModes, the user may trigger another system actionmode (The text copy/paste/select). In that case, onDestroyActionMode is called and I erroneously asume the user is done with the first actionmode, rather than implement a "stack" functionality, so can I ignore this onDestroyActionMode, let the user edit / cut / etc the text, then reopen the former actionmode when done.
我怎样才能做到这一点？
How can I achieve this?
推荐答案
脱落您的情况进一步光：到蜂窝上一个TextView，长preSS将产生与选项的弹出窗口（如选择单词之前， 全选和添加someword到词典），同时不影响任何现有的ActionMode既所示，当并驳回时（由pressing背面）。因此，这不是一个真正的问题pre-蜂窝。
Shedding further light on your situation: prior to honeycomb, longPress on a TextView will yield a popup window with options (like 'Select word', 'Select all', and 'Add "someword" to dictionary') while NOT affecting any existing ActionMode both when shown and when dismissed (by pressing back). So this isn't really a problem pre-honeycomb.
有关的HTC Sense越光：感觉不接受TextView.setCustomSelectionActionModeCallback（），因为感觉不使用ActionMode文本选择功能（并明确不在乎，如果世界其他地方做！）。所以这个问题已经在这种情况下不同的气味（我没有测试下检测下面的解决方案，所以不知道它会如何表现）。
More light regarding HTC Sense: Sense does NOT honour TextView.setCustomSelectionActionModeCallback() because Sense doesn't use an ActionMode for the Text selection feature (and clearly don't care if the rest of the world do!). So this problem has a different smell in that situation (I haven't tested the following solution under Sense, so not sure how it'll behave).
一个解决方案是创建任何TextView的和/或EditText上你的愿望（虽然只有当设备运行蜂窝或更高版本）的自己的自定义ActionMode.Callback更换操作系统的一个，在setCustomSelectionActionModeCallback应用它（）。通过自定义onTextSelectionCABDestroyed回调接口到自定义ActionMode.Callback，把它在onDestroyActionMode方法。
A solution is to create your own custom ActionMode.Callback to replace the OS's one and apply it in setCustomSelectionActionModeCallback() of any TextView and/or EditText you desire (though only if device is running honeycomb or greater). Pass a custom onTextSelectionCABDestroyed callback interface to your custom ActionMode.Callback, call it in the onDestroyActionMode method.
首先创建一个接口，并要处理原来的ActionMode的娱乐实现它（或者你可能想使用一个总线事件的东西，如奥托）：
Firstly create an interface and implement it where you want to handle the recreation of your original ActionMode (alternatively you may want to use a bus event with something like Otto):
public interface YourCallbackInterface {
public void onTextSelectionCABDestroyed();
}
和创建一个新类：
public final class CustomTextSelectionActionModeCallback implements ActionMode.Callback {
WeakReference<YourCallbackinterface> mYourCallbackinterface;
public CustomTextSelectionActionModeCallback(YourCallbackinterface yourCallbackInterface) {
mYourCallbackinterface = new WeakReference<YourCallbackinterface>(yourCallbackInterface);
}
@Override
public boolean onActionItemClicked(ActionMode mode, MenuItem item) {
return false;
}
@Override
public boolean onCreateActionMode(ActionMode mode, Menu menu) {
return true; //returning true will create the ActionMode
}
@Override
public void onDestroyActionMode(ActionMode mode) {
//this is the magic where we actually capture the destroy event for TextSelectionCAB and can subsequently do things like recreate the ActionMore that TextSelectionCAB greedily destroyed!
mYourCallbackinterface.get().onTextSelectionCABDestroyed();
}
@Override
public boolean onPrepareActionMode(ActionMode mode, Menu menu) {
return false;
}
}
和记住不要StackOverflowException时重新从ActionMode的onDestroyActionMode的ActionMode，postDelayed一个Runnable到这样的处理程序我在这里解释一下：Reopen ActionMode（或CAB）onDestroyActionMode被称为后
And remember to avoid StackOverflowException when recreating an ActionMode from the onDestroyActionMode of an ActionMode, postDelayed a Runnable to a Handler like this I explain here: Reopen ActionMode (or CAB) after onDestroyActionMode is called
最后，如果你使用ActionBarSherlock，请确保您的CustomTextSelectionActionModeCallback实现android.view.ActionMode.Callback而非com.actionbarsherlock.view.ActionMode.Callback。
Lastly, if you're using ActionBarSherlock, make sure that your CustomTextSelectionActionModeCallback implements android.view.ActionMode.Callback rather than com.actionbarsherlock.view.ActionMode.Callback.
请注意：我还没有与ActionBarCompat所以不知道这一切是如何应用这里举行。如果有人知道，请发表评论作为！
Note: I haven't played with ActionBarCompat so not sure how all this applies there. If someone knows, please post as comment!
这篇关于检测ActionMode嵌套的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！