Could we have the ability to toggle the visibility of a tab in a tab panel ?

aosborne

I'm not sure if it fits in with your plans, but it would be nice to toggle a tabs' visibility. Sometimes changing an option on one tab could make additional tabs appear or disappear.
I currently have use for this in a desktop app, but think it would also be handy on web pages.
Any, please consider.
Cheers.
Adam

ebloom

Some additional tab panel suggestions. Some of these might be very specific to my app, but they may be useful to others.

When there are more tabs than fit current behavior is to split into rows. Can there be an option for a single row with left & right arrows at the end of the row?
Allow tabs to be re-ordered by dragging, similar to column re-order in list box?
A way to create a context menu for a tab by right-clicking on the tab caption? Maybe the MouseDown event indicates which tab it occurred in? Needs to be separate or distinguishable from a click inside the tab.
Option to add buttons within the tab captions, similar to the system symbol in a button, but needs a Pressed handler for each button. And the handler needs to pass which tab it is in.
Other tab panel implementations allow tabs to be located at the bottom or either side.

Background info: I've started thinking about converting an existing Xojo desktop app to Objo. It uses tabs - lots of them. In Xojo I ended up faking the tabs using containers. Each tab is a container that includes a small red X close button, and the ability to show a context menu. Then a container to hold all the individual tabs. Attached image is from the Xojo app.

I know this is a lot. And most or all is probably doable with containers and classes. But no point in doing it the hard way if the framework supports it. Thank you!

Garry

Thanks for these suggestions. I think they would be useful beyond the specific applications described here, so I’ve logged six separate accepted feature requests and settled the main behaviour for each.

Show and hide individual tabs
Hiding a tab will preserve its controls and values without changing the other tabs’ indices. If the selected tab is hidden, selection will move to the next visible tab, or the previous one if necessary. Hidden tabs will also be skipped during keyboard navigation.
Scrolling headers with arrow controls
Desktop TabPanels will gain an optional single-row scrolling mode, with wrapping remaining the default. Web already scrolls its headers horizontally, so I’ll add arrow controls there too. Selecting an offscreen tab will bring its header into view automatically.
Context menus for Desktop tab headers
A dedicated event will identify the tab targeted by a secondary click or keyboard context-menu action. Opening a menu for an unselected tab won’t switch pages.
Optional close buttons for Desktop tabs
Applications will be able to show close buttons and control which tabs can be closed by the user. Clicking a close button will raise a request, leaving application code to prompt about unsaved changes and decide whether to remove the tab.
Runtime reordering of Desktop tabs
Tabs will be movable through code, with optional dragging and keyboard reordering. Moving a tab will preserve its controls and values and keep the same logical tab selected.
Desktop tab placement on all four sides
Headers will be positionable at the top, bottom, left or right. Side tabs will retain horizontal captions, and the visual designer will preview the chosen placement.

Visibility and scrolling are planned for both Desktop and Web. The other four requests are Desktop-only initially, since Web currently has a fixed design-time tab structure.

For buttons within captions, I’m initially supporting the close-button case rather than arbitrary collections of buttons. I’ll implement these improvements in stages, starting with visibility and the shared groundwork.

Garry

I’ve now implemented showing and hiding individual tabs for both Desktop and Web. It will be available in the next release.

The API uses two TabVisible overloads:

TabVisible(index) returns whether a tab is visible.
TabVisible(index, visible) shows or hides it.

For example, put this in the window or page’s Opening handler to start with the third tab hidden. Tab indices are zero-based:

TabPanel1.TabVisible(2, False)

Then, in the handler for the option that makes that tab relevant, you can reveal it:

TabPanel1.TabVisible(2, True)

This should cover the workflow Adam described, where changing an option makes additional tabs appear or disappear.

Hiding a tab preserves its controls and their current state. If someone enters text, changes a value, or scrolls within a tab, that work remains when the tab is shown again. Showing it does not rerun constructors or Opening.

A few details about selection:

Hiding a tab leaves every other tab’s index unchanged. TabCount still includes hidden tabs.
Hiding the selected tab selects the next visible tab to its right, falling back to the nearest visible tab on its left.
If every tab is hidden, SelectedTabIndex becomes -1. Revealing a tab then selects it. Otherwise, revealing a tab preserves the current selection.

Hidden tabs are skipped during keyboard navigation, and focus moves out of content that becomes hidden.

Studio continues to show every authored tab so you can edit its contents normally. Visibility is controlled at runtime through code, including from Opening.

I’ve also added TabID(index) and TabIndexFromID(id) for identifying a particular tab independently of its current index. Those IDs belong to the running panel instance and should not be saved between runs.

This completes the visibility part of the requests above. I’ll continue working through the other TabPanel improvements in stages.

Garry

I’ve now completed the scrolling TabPanel headers work for Desktop and Web. It will be available in the next release.

On Desktop, set TabOverflowMode to Scroll in the Inspector’s Tabs section to keep the headers on a single row. Wrapping remains the default for existing panels.

You can also set it in code. For example, in the window’s Opening handler:

TabPanel1.TabOverflowMode = .Scroll

I settled on a compact double-chevron menu for handling overflow. When the headers don’t fit, the chevron appears at the right. Clicking it lists all visible tabs, with the current tab checked, so you can jump straight to the one you want. Hidden tabs are excluded.

Selected and keyboard-focused headers are brought into view automatically, and trackpad scrolling remains available.

Web TabPanels keep their existing single scrolling row and gain the same chevron menu, with touch scrolling preserved. Both designers preview the overflow behaviour too.

This completes the visibility and scrolling improvements. I’ll continue working through the remaining TabPanel requests in stages.

Garry

I've now completed optional close buttons for TabPanels on both Desktop and Web. These will be available in the next release.

Enable ShowCloseButtons in the Inspector's Tabs section to display them. The setting defaults to False. You can also use SetTabClosable(index, False) to protect individual tabs, such as a permanent home tab.

Clicking a close button raises TabCloseRequested(tabID As String). Your handler decides whether to close the tab, allowing you to check for unsaved changes or ask for confirmation first. Without a handler, the tab stays open. Clicking the cross on an unselected tab doesn't switch to it.

For Desktop, add the TabCloseRequested handler to TabPanel1 in Studio. It receives tabID As String. To accept requests immediately, paste this into its body:

Var index As Integer = TabPanel1.TabIndexFromID(tabID)
If index >= 0 Then TabPanel1.RemoveTab(index)

Web retains its fixed authored tab structure, so accepting a close request hides the tab while preserving its controls and values. Use this body for the Web handler:

Var index As Integer = TabPanel1.TabIndexFromID(tabID)
If index >= 0 Then TabPanel1.TabVisible(index, False)

The ID identifies the particular tab independently of its caption or current index. If your handler awaits a save or confirmation, resolve the ID again afterwards and guard against overlapping prompts.

Delete also requests a close when an eligible tab header has keyboard focus. Inside a text field, it keeps its usual editing behaviour.

Both designers preview the close buttons. Clicking a preview cross selects the panel for editing; deleting an authored tab remains an undoable action in the Inspector's tab list.

This covers the close-button use case from your example.

Garry

I’ve now implemented runtime tab reordering for both Desktop and Web. It will be available in the next release.

To let users reorder tabs, enable AllowTabReordering in the Inspector’s Tabs section. You can also enable it in code, for example in Opening:

TabPanel1.AllowTabReordering = True

Users can then drag a tab header to a new position. An insertion marker shows where it will go. For keyboard reordering, focus a header and use Control+Shift+PageUp or Control+Shift+PageDown. These use Control on macOS too.

Reordering preserves each tab’s controls and their current values. The same tab remains selected, including when dragging an unselected tab past it. User reordering defaults to False, so applications enable it explicitly.

You can also move tabs through code without enabling user reordering:

TabPanel1.MoveTab(0, 2)

Indices are zero-based, and the destination is the tab’s final position. For tabs [A, B, C, D], that produces [B, C, A, D]. Hidden tabs still count towards these indices.

The new TabReordered event reports the tab ID, its old and new indices, and whether the move came from user input or code. Runtime moves affect the running application; they don’t change the saved designer layout or automatically save an order between runs.

I’ve also adjusted the scrolling default mentioned earlier: new Desktop TabPanels now use Scroll by default. Existing panels retain their previous behaviour, and Wrap remains available in the Inspector.