Both DENY and DEFER are a form of veto. A "defer" vote means "I don't agree right now, but if you ask me again later, I will agree", whereas "deny" means "I don't agree now and I make no guarantee about what might vote might be later". So, it may be OK for TerraTabPaneSkin to behave this way in response to a "defer", but not a "deny".
Maybe we need to reset the prior button group selection in selectedIndexChangeVetoed()? On Sep 6, 2010, at 4:08 PM, Chris Bartlett wrote: > How should a TabPane behave if it has a TabPaneSelectionListener which always > returns Vote.DENY in the previewSelectedIndexChange() method? (A contrived > example, but demonstrates the point) > > With TerraTabPaneSkin, if I select a tab by clicking the mouse on an enabled > TabButton, the selection change is vetoed. > However by this point, the 'target' TabButton has been selected and repainted > and the TabPane's appearance is left in an inconsistent state. > > > If TabPaneSelectionListener#previewSelectedIndexChange() provides the ability > to veto, shouldn't it be tied in to the enabled state of the various tabs? > That might open a can of worms though, as the votes returned by the various > TabPaneSelectionListeners might change arbitrarily. > > Enabling & disabling tabs seem to provide similar functionality, with the > exception of the TabPaneSelectionListener#selectedIndexChangeVetoed() method, > which I suppose could be used to explain to the user why they are not able to > select an enabled tab > Enabling & disabling tabs has the advantage of updating the GUI to indicate > the availability of the tabs for selection > > Regards, > > Chris
