Re: Proposed tabbed_pane widget changes
Michael Flanagan <[email protected]>
| Newsgroups | gmane.comp.windows.devel.netwindows |
|---|---|
| Message-ID | <[email protected]> |
Alex Russell wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>Next item. There is no mechanism to have the widget automatically >>switch to the next tab other than by clicking on it. >> >> > >I think that Shift-left and Shift-right keystroke modifiers (or >something similar but not caught by the browser) might also be useful >here. > > Ya, I thought of that too, but it would conflict with our internal table widget which already co-opts those keys. I'm still trying to think this one through. >>I would like >>to implement the capability so that when you 'blur' off the last >>input/button/select/textarea element on the pane, it automatically >>makes visible the next pane in the tab order. >> >> > >Um, what if I got to a previous element in the same container? Do I >then still get switched? > >I think the intended behvior here is to move to the next tab if I >tab-through the last input element, not necessarialy if I blur off of >the last one. > Correct. I believe we can check to see what other key's were in effect at the time of the 'blur.' If a modifier key was also in effect, then we would not change pane's. Only if it was a 'tab forward' so to speak (provided you were on the last tab). >>Also, the current tabbed_pane widget doesn't play nice when used in >>forms. It seems as though it was intended as a display only >>mechanism. I would like to chance it's current behavior which is to >>actually sub out the content of the pane (it basically does DOM >>node swapping) for a different one, to a system where the >>visibility of a pane is determined by a CSS style of hidden / >>visible = false, whatever it is. This would have the benefit that >>the form fields would actually exist in the DOM then when a submit >>was done. >> >> > >I think this makes some sense. Although this brings up the question of >whether or not all tabs are treated as a single form or multiple >forms? > Ya, this I don't know about.... for now I'm happy that we're ahead of the old tabbed_pane widget (we have this working with the hidden div thing now). _______________________________________________ The netWindows developers list: [email protected] http://netwindows.org/mailman/listinfo/devel_netwindows.org