Community
Participate
Working Groups
It would be nice to have a setEnabled()-function for CTabItems.
*** Bug 79042 has been marked as a duplicate of this bug. ***
Yes, please!
Is there any development planned??
LS, do you have time to fix this bug ? It shouldn't be too hard I expect. It has quite a few votes.
Created attachment 146811 [details] patch-v1 Created initial version of the patch. It provides setEnabled and getEnabled APIs. This is the behavior of a disabled CTabItem using the patch: 1) User can't select the tabItem through UI and setSelection API. 2) When the selected tabItem is disabled, the control is also disabled, else control is not disabled. Then, the control's state will be restored if required, when selection is changed or when the control is enabled. 3) traversing through the tabItems will skip the disabled tabItems. 4) if the 0th tabItem is disabled, the next enabled tabItem is selected for the initial selection. Carolyn, please review the patch and comment if this is the right way to go.
Created attachment 146812 [details] test case
I don't think that the behavior describe in number 2) is necessary. If the tabitem cannot be selected, its control is never visible, so it does not matter if it is enabled or not. It believe it is also wrong to try to keep the enable state of the control (CTabItem.controlEnabled). The app code can change this state anytime and the var would get out of date. What happens if there is only item it is disable? I just want to make sure it works and it does not look bad. Not very important, but the indentation is a bit funny in some of the chagnes in CTabFolder (for example, onFocus());
> I don't think that the behavior describe in number 2) is necessary. If the > tabitem cannot be selected, its control is never visible, so it does not matter > if it is enabled or not. I added this to handle the case where the tabItem is selected first and then it is disabled. Should the control of disabled tabItem never be visible? If so, then in this case I can hide the control for the disabled tab. The CTabItem.enabled was added to handle this case and when there are shared controls. But, there was a problem when state of control changes anytime. If the control should not be visible then this will not be required. > What happens if there is only item it is disable? With the patch, when there is only 1 disabled tabItem, the tabItem is visible but it'll not be selected, hence the control is not visible. But, if the tabItem is disabled after selection, then control is visible and disabled. I think the indentation looks odd only in diff view but it is inline with the code. :)
I beleive the control enable/disable state should not be played with. If the selected tab item becomes disabled, the selection should go back to -1 (no selection) and the control should not be visible. I believe the selection already goes back to -1 when the selection tab item is disposed, for example. The tab item should draw disable as well, but I do not think there is API for this (see bug#22782).
Created attachment 147320 [details] patch-v2 Thanks Silenio! I have modified the patch based on your comments: If the selected tab item becomes disabled, the selection should go back to -1. I removed the forceFocus() because the disabled tabItem can't be selected, so it is not required. I also checked to see what happens when a selected tabItem is destroyed, the selection changes to the previous tabItem.
The patch looks good (there are still some formatting issues - are you using spaces instead of tabs?). Also, I would just return enabled; from getEnabled()instead of return this.enabled; However, I don't think we should release this patch until bug#22782 has been fixed, because it would be really misleading to have a disabled tab that does not have any "disabled" appearance in the UI. Users would wonder why they can't select the tab. For the final testing (after bug#22782 is fixed), you will want to have images in your test case to make sure they look good with the "disabled" look also. And you'll have to be sure to test on multiple platforms. So this bug is now waiting on bug#22782.
(In reply to comment #11) > The patch looks good (there are still some formatting issues - are you using > spaces instead of tabs?). Also, I would just return enabled; from > getEnabled()instead of return this.enabled; > > However, I don't think we should release this patch until bug#22782 has been > fixed, because it would be really misleading to have a disabled tab that does > not have any "disabled" appearance in the UI. Users would wonder why they can't > select the tab. > > For the final testing (after bug#22782 is fixed), you will want to have images > in your test case to make sure they look good with the "disabled" look also. > And you'll have to be sure to test on multiple platforms. > > So this bug is now waiting on bug#22782. Hello Commiters When this bug would be fixed(and alse 22782)..I have a urgent requirement..
