TabSet add/remove tab

[acarur01]

I'm trying to show/hide tabs using addTab/removeTab with destroyPanes set to false. My problem is that I get the flag to add/remove the tabs BEFORE the tabset is drawn so the tabs I've tried removing shows up anyway. Any ideas on how to get around this?

[Isomorphic]

What do you mean by "I get the flag .. before the tabset is drawn"?

Regardless, if you don't want the pane destroyed, just set the pane to null via updateTab immediately before you remove the tab.

[acarur01]

This add/remove tab happens dynamically. As in I don't know the exact instance in which I will need to call addTab/removeTab on the tabset.

Your previous answer does not help me at all. It's not the destroying or lack there of that I am having problems with.

My problem is that I get in certain instances the request to add/remove a tab before the tabset is even created.

[Isomorphic]

OK, you're using terminology that seems to be specific to some kind of framework you've built above SmartClient (like references to a "request" to add a tab). Right now, it sounds like this is an issue entirely outside of SmartClient. If you think there's a SmartClient-related problem here, try to frame the problem purely in terms of SmartClient.

[acarur01]

Have you been reading what I have been writing in this thread? I am not saying that it is a SmartClient issue. Rather I am asking for suggestions on how to go about dealing with a situation like the one I currently have.

I have a tabset with a number of tabs in it. In between rendering of this tabset, there is an action that occurs within our framework that tells me I should not display this tab. At this point, when I access the tabset, the tabs have not been added yet. My question is can I get around this by saving the tab IDs that I should not be displaying so that when the tabset is finally fully drawn with the tabs I know to hide them.

My scenario is that when I am accessing this tabset, the tab I want to remove does not exist yet so I cannot remove it. But after this process, the tab gets added and it is still displayed.

[Isomorphic]

Yes, we always read your posts. The problem is, you're making references to application-specific situations that we don't understand because we didn't write that code. Try to frame the problem in terms of SmartClient, then we can help.

[damend]

Hi,

it's related to :
http://forums.smartclient.com/showth...light=tab+hide

using 02-27-2012

I'm in a similar situation.
Instead of hiding the tab-option, I tried to add tab if it has to be added, otherwise not.
This makes my code worse and somehow, it will remove other tabs.

So, how do you think about a hide/show for specific tabs inside of a tabset?

- I'll try to make this remove and adding working.

Thanks,

[Isomorphic]

A hide() / show() interface would be eligible for Feature Sponsorship, but it would be just a convenience relative to current functionality.

[acarur01]

We have had issues with Tabsets for quite a while and our solution for it was to create our own custom with buttons that look like the tab bar buttons. Below are a list of points we found while using Tab sets - please let me know if these are still the case today. If at all possible, we would like these issues addressed by SmartClient instead of our own custom tabset implementation.

1. When creating a tab set in browser, all tabs have to be created and initialized.

This is a problem for us because each tab pane will require a fetch of the form we want to display in the given tab pane even though it is not currently visible.

It would be helpful if you could shed light on why creation/initialization of tab panes is necessary for ones that are not yet viewed by the user.

2. We've found no reliable way of being able to show/hide tabs dynamically - this includes the tab bar button as well as the tab pane.

3. Tab selected event: always comes AFTER the tab is already selected and shown in the tabset (Smart Client behaviour, no way to squeeze between moment when user clicks on the tab button and before the new tab content is shown).
This
a) increases tab selection event response (when need to refresh/change something on the selected tab), creates visible delay;
b) when need to force staying on the previous tab (for ex., in case of validation errors) it looks ugly when first it shows the new tab but then selects the previous tab back (as result of server response).

4. One functionality we have lost since moving to SmartClient is the ability to, when there is only one tab visible, hide all tab buttons as they are unnecessary clutter on the screen.

[Isomorphic]

No, none of these are issues, or ever have been..

1. use addTab() to add tabs after init, and you can lazily create panes in tabSelected()

2. use removeTab / addTab

3. if you're doing a server request to detect whether it's legal to go to the new tab, the last thing you want to do is not show the new tab as selected, because that's going to look like the application just didn't respond. If anything, consider hiding the tab.pane component until the server request completes

4. just pop the tab.pane out and place it in a new container, hiding the TabSet

[acarur01]

for #3 - the only time we would refrain from changing the selection of the tabset is to show an error on the previously viewed tab pane in which case there IS a visible indication of response.

I will look into the rest of your suggestions. Thanks

[acarur01]

So is there a hook that we can use like "onSelectionChange" which would be fired before selectedChanged?

[Isomorphic]

No, there's no earlier notification. Again, we think the brief changing and changing back is a plus since it shows that the TabSet responded to your click. Even if there's an error on the previous tab, if it's an error that's already showing, then without the change and change back effect it could look like there was no response to the click.

[acarur01]

But we could easily get around this by displaying a message saying to fix the validation errors first. To us it really isn't an issue about response indication. Some applications might even want to override this so that the previous form is validated but still allow the user to go to the next tab. For others its a simple "You cannot go to the next step until the previous still is valid."

Anyway, it looks like I'm not going to win this argument.

[Isomorphic]

You can always "win this argument" by deciding that it's important enough that you want to sponsor an earlier notification and have us re-work some of the TabSet events to enable this - it's just not going to be regarded as a bug when we actually think the way it works now is better :)