微调项目的上下文菜单
我将如何向微调弹出窗口添加上下文菜单？
我有一个由数据库光标填充的微调器，我想要一个上下文菜单，这样当用户长按某个项目时，他们可以编辑或删除该项目（上下文菜单中的两个选项）。
我似乎找不到一种方法来为与可选项目一起出现的窗口注册上下文菜单。有没有办法，比如在列表视图上？
否则，如果有一个为上下文菜单注册的隐藏视图，然后使用微调器的 OnItemLongClickListener 调用 openContextMenu 来获取隐藏视图，该怎么办？这看起来有点像黑客，所以如果可能的话，我宁愿以正确的方式进行。
或者也许我应该只注册上下文菜单的微调器，而不是隐藏一个......
谢谢！
How would I go about adding a context menu to a spinner popup?
I have a spinner that is populated by a database cursor, and I'd like to have a context menu so when the user long clicks an item they can edit or delete the item (two options in context menu).
I can't seem to find a way to register a context menu for the window that appears with the selectable items. Is there a way to, like on a list View?
Otherwise, what about having a hidden view that is registered for a context menu and then use the spinner's OnItemLongClickListener call openContextMenu for the hidden view? This seems kind of like a hack so I'd rather do it the correct way, if possible.
Or maybe I should just register the spinner for the context menu instead of having a hidden one...
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
理想情况下，你甚至不会尝试。经典的弹出式上下文菜单将在新的 Honeycomb UI 中被淘汰，至少对于平板电脑的外形尺寸而言是如此，因此我不会投入大量时间将它们侵入到通常不使用的小部件中。
此外，用户不太可能发现您的上下文菜单，仅仅是因为他们一开始就不会太频繁地发现上下文菜单。用户往往不会通过随机地刺击屏幕一秒以上来尝试是否会弹出菜单。他们了解上下文菜单的唯一方法是阅读精美的手册，我们都知道这种情况发生的频率。因此，您需要一些其他方式让用户执行相同的操作 - 让他们只能通过不可发现的上下文菜单进行编辑/删除是非常不利于用户的。因此，上下文菜单充其量只是一种促进剂，不值得强行进入意想不到和不受支持的地方。
如果您需要上下文菜单，请将
Spinner转换为ListView。这不仅会逐渐变得更容易被发现（如果某些用户长按列表项，他们会习惯有趣的事情），而且上下文菜单也会自然地工作。如果您确实愿意，可以将
Spinner（可能还有AbsSpinner或其他超类）克隆到您的项目中，这样您就可以控制下拉行为，然后编写一些内容启用选择对话框上的上下文菜单。然后，您需要记住，这一切很可能在 Android 3.0 中的新Spinner中不起作用，仅仅是因为不再有选择对话框。Ideally, you wouldn't even try. Classic pop-up context menus are going to be obsolete with the new Honeycomb UI, at least for the tablet form factor, so I would not invest a ton of time in hacking them into widgets where they aren't normally used.
Moreover, users are unlikely to discover your context menu, simply because they tend not to discover context menus too often in the first place. Users tend not to experiment by randomly stabbing the screen for a second-plus to see if menus happen to pop up. The only way they will know about your context menu is if they read the fine manual, and we all know how often that happens. Hence, you need some other way for the user to do the same operations -- having them be able to edit/delete only through a non-discoverable context menu is very user-hostile. Hence, context menus are, at best, an accelerant, and not worth forcing into unexpected and unsupported places.
If you want the context menu, convert the
Spinnerinto aListView. Not only will this be incrementally more discoverable (some users will be used to interesting things if they long-tap on a list item), but context menus work naturally.If you really want, you can clone
Spinner(and possiblyAbsSpinneror other superclasses) into your project, so you can take control over the drop-down behavior, then write something that enables a context menu on the selection dialog box. Then, you will need to bear in mind that none of that will work, most likely, with the newSpinnerin Android 3.0, simply because there is no more selection dialog box.