I have a UI where the user selects "menu" items from an explorer bar on the left, tabs are displayed on the right (a splitter holds both). tabs are opened to contai child forms for each action.
When the user hits "save" on a child form in a tab I want to close the tab. I can call a javascript function on the parent form with the relevant details (not having a Key property for each tab is a problem, though it can be worked around - and this is necessary because I have no control over the order in which tabs will be created or destroyed - so the index is useless)
However I need to close the tab. there doesn't seem to be a method for this? Errr, this is a rather large functional hole if its true - can anyone enlighten me?
(The curent workaround is ugly - I have to trigger a postback)
Hello Peter,
I guess the close button is overlapping because the tab headers doesn’t fit within the width of the tab. You can try to set the property TabsOverflow of the webtab to KeepSize. You can find more information about this here:
http://help.infragistics.com/Help/NetAdvantage/ASPNET/2010.1/CLR3.5/html/WebTab_Handling_Overflow_in_WebTab.html
The close button can be either present or not present for all the tabs. You cannot have some tabs with a close button and some without. There is no way to remove the close button on the client, there you can only check if it is present.
The reason you should take the tab.get_tabs().length is that the get_tabs() returns a normal Array object, and not some custom-created collection object, and the way to take the number of the elements of an Array with javascript is with the length property.
Hope this helps.
Regards,
Lyuba Petrova
Developer Support Engineer
Infragistics
www.infragistics.com/support
I beg to differ. If you create a tab server side, you CAN have a mixture of tabs with an without the close button, the screen shot below demonstrates this. Its only in the client side API that this isn't possible.
I reported the .length property thing because you've gone to extreme measures to be consistent throughout the rest of the client object model - this seemed to be a oversight (and at the least, was confusing on my end).
I will look at the overflow property, but again, the main point is that this is being handled inconsistently between client and server side code.