Saturday, December 19, 2009

context menus and transmitting state to a dialog

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()) {



            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:

AdapterContextMenuInfo info = (AdapterContextMenuInfo) item.getMenuInfo(); // now is the rowid given by the adapter for the item

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.


No comments:

Post a Comment