I basically have the same problem as reported here: putting a button or other focus-receiving object on a ListView blocks it from receiving item selections because those need to be focus-receiving too. Tricky. I guess that makes sense, though, how would you navigate without a touch-screen? So I guess it’ll be context menus for my “log it now” function although there could be ways around it on a touch screen.
Next problem: I’m using a context menu and one of the functions is to delete. Before deleting something the user accidentally touched, I want to show a dialog, then delete it if they confirm. Problem: there doesn’t seem to be any way to hold on to the item in question while the dialog is shown, except for using a class member (which seems really messy).
public boolean onContextItemSelected(MenuItem item) {
Log.d(TAG, “onContextItemSelected”);
switch(item.getItemId()) {
case R.id.ilc_menu_delete:
showDialog(DELETE_DIALOG);
return true;
}
return super.onContextItemSelected(item);
}
You can’t pass any information to showDialog; the dialog is actually shown via a separate callback. In fact, it’s worse than that – I don’t even have information when the context menu is clicked, or when it’s created from the list item! OK – checked the docs; you can get the item that was selected, it’s just rather convoluted:
But you still have to stash that ID somewhere while the dialog is shown. So for now I’m putting it in a member for the transition. Once the dialog is created, the ID can be captured in a listener. That works OK. The indirection for requesting a dialog versus showing it is a bit puzzling.
[Via http://sosiouxme.wordpress.com]
No comments:
Post a Comment