can't re-show the dialog in onClick(), because it's already shown. at least that was true with 1.1, i should check it with a later SDK.
so either i do my validation in onDismiss(), or i get all fancy. >Just ran a quick test on my code and you're right! Sorry for the >wrong info. I've been manually calling dismiss() and cancel() on the >dialogs I use. It's been a while since I looked at that code and >figured I was doing that because I had to ... now this makes me >wonder why I did it that way to begin with =P. > >But you should still be able to do validation on the OK button being >clicked, and if that fails, just re-show the dialog. > >"as i can't schedule a reappearance of the dialog in the onClick()" > > >Why not? If you define your click handler inline within the activity >that's using it, you can just call showDialog(ID) in onClick(), no? >Or does that not work? > >------------------------------------------------------------------------------------------------- >TreKing - Chicago transit tracking app for Android-powered devices ><http://sites.google.com/site/rezmobileapps/treking>http://sites.google.com/site/rezmobileapps/treking > >On Fri, Nov 20, 2009 at 1:20 PM, Jason Proctor ><<mailto:[email protected]>[email protected]> >wrote: > >thanks for the response, most helpful. > >i don't actively dismiss the dialog at any point, therefore something >behind the button click must be doing it. i took a look in >android.internal.app.AlertController.java, and found that its click >listener calls the appropriate button handler, then sends a dismiss >message to the dialog. unless i'm missing something big, seems fairly >conclusive. > >so the reasons why i do it this convoluted way are coming back to me. >due to the auto-dismiss, i have to validate in the dismiss handler, >as i can't schedule a reappearance of the dialog in the onClick(). > >i suppose i'll have to get all fancy and do the validation key by key, then. > >(the point remains that Android has the weirdest modal dialog >handling of any environment i've encountered!) > >thanks, >J > > > >>"when the dismiss listener fires, can i tell which button caused >>the dismiss?" >> >>No - I don't think any of the buttons by default cause the dialog to >>be dismissed. This happens when you call dismiss() or cancel() on >>the dialog or the user presses the back button. >> >>"so in the click listener, i set a member flag according to which >>button was clicked. then in the dismiss listener, i then check the >>flag to see whether to proceed or not" >> >>But you have set on click listeners for each of the two buttons you >>have, no? So why not handle their actions in their respective click >>listeners? What are you doing in each of those listeners (I'm going >>to bet you're dismissing the dialog after storing the flag...)? >> >>"the other issue i have with Android's dialogs is that if the >>contents fail validation and the dialog needs to be re-presented, i >>have to re-show it in the dismiss listener" >> >>No, you don't have to do this. In your listener for the OK button >>you can get the text field, validate it, and if it fails show a >>toast message, and don't dismiss the dialog. If it succeeds, do what >>you need to with the entered data and THEN call dismiss() on the >>dialog. >> >>If you want to get fancy you can also validate the user data as they >>type and disable and enable the OK button in response so they can >>only hit OK when they've entered valid data. >> >>Also, I highly doubt you need the dismiss listener in your case. >>Hope that helps. >> >>------------------------------------------------------------------------------------------------- >>TreKing - Chicago transit tracking app for Android-powered devices > > > ><<http://sites.google.com/site/rezmobileapps/treking>http://sites.google.com/site/rezmobileapps/treking><http://sites.google.com/site/rezmobileapps/treking>http://sites.google.com/site/rezmobileapps/treking > > > >>On Thu, Nov 19, 2009 at 8:00 PM, Jason Proctor > > > ><<mailto:<mailto:[email protected]>[email protected]><mailto:[email protected]>[email protected]> > > >wrote: >> >>i never look forward to handling Android dialogs, maybe someone can >>point me to a better way of doing it than i'm doing right now. >> >>say i have a dialog which has one text field in it, and OK and Cancel >>buttons. i make the dialog with AlertDialog.Builder, and set click >>listeners on the buttons and dismiss listener on the dialog. >> >>when the dismiss listener fires, can i tell which button caused the >>dismiss? i don't see how, so in the click listener, i set a member >>flag according to which button was clicked. then in the dismiss >>listener, i then check the flag to see whether to proceed or not. a >>rather backward process. am i missing something? >> >>the other issue i have with Android's dialogs is that if the contents >>fail validation and the dialog needs to be re-presented, i have to >>re-show it in the dismiss listener. in every other environment known >>to man, dialogs are (somewhat) modal, so the dialog stays up unless >>expressly dismissed by code. IMHO, the latter makes more sense. >> >>thanks for any help with this stuff, >>-- >>jason.vp.engineering.particle >> >>-- >>You received this message because you are subscribed to the Google >>Groups "Android Developers" group. >>To post to this group, send email to > > > ><mailto:<mailto:[email protected]>[email protected]><mailto:[email protected]>[email protected] > > >To unsubscribe from this group, send email to > > > ><mailto:<mailto:android-developers%[email protected]>android-developers%[email protected]><mailto:android-developers%[email protected]>[email protected] > > >For more options, visit this group at > > > ><<http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en><http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en > > > >> >>-- >>You received this message because you are subscribed to the Google >>Groups "Android Developers" group. >>To post to this group, send email to >><mailto:[email protected]>[email protected] >>To unsubscribe from this group, send email to >><mailto:android-developers%[email protected]>[email protected] >>For more options, visit this group at > > > ><<http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en><http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en > > >-- > >jason.vp.engineering.particle > >-- >You received this message because you are subscribed to the Google >Groups "Android Developers" group. >To post to this group, send email to ><mailto:[email protected]>[email protected] >To unsubscribe from this group, send email to ><mailto:android-developers%[email protected]>[email protected] >For more options, visit this group at ><http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en > > >-- >You received this message because you are subscribed to the Google >Groups "Android Developers" group. >To post to this group, send email to [email protected] >To unsubscribe from this group, send email to >[email protected] >For more options, visit this group at ><http://groups.google.com/group/android-developers?hl=en>http://groups.google.com/group/android-developers?hl=en -- jason.vp.engineering.particle -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
