Double-click on TabControl Active Tab: An/Any Event? (1 Viewer)

[riktek]

In the realm of stupid questions, but I've not had to do this before and my Google-Fu has failed me:

Which, if any, event occurs when one double-clicks on a TabControl object's tab, perhaps otherwise referred to a Page object's tab? More specifically, on the active tab / tab for the active page?

TabControl.DoubleClick occurs when one double-clicks in the area to the right of existing tabs. A single click on an inactive tab of course triggers Change but that's not germane.

Page.DoubleClick occurs when one double-clicks on the page body outside of any control.

Neither occurs when one double-clicks on the tab itself for a particular page. (Again, I'm most interested in the active tab.) I'm left wondering whether any events occur, which would be unfortunate because it is an obvious click target. Of course, I'd prefer not to have to create a redundant subform label just to obtain a functional click target.

 

[MajP]

I think you are stuck with putting a transparent control there. You can try a command button (transparent, no caption, no border).
Out of curiosity what does it do. You say "obvious click target", but I cannot think of any time I would want to double click the tab.
If you do not like the effect that way you could set the tab control to no tabs, and then place your own labels or buttons above the tab. Then you can do things like color them too.

 

[The_Doc_Man]

According to the linked article below, a tab control's double-click event exists. It would be subject to the same rules as other click and double-click events for the more common control types.

TabControl object (Access)

Office VBA reference topic

learn.microsoft.com

If your double-click doesn't appear to work, some questions come to mind.

First, do other double-click events work normally for controls that are on that form and NOT associated with a tab-control?

Second, when you double-click that tab control, does it seem that at least a single-click event fires? Or do you get nothing?

Third, does any message appear when you try to click or double-click the tab control?

 

[theDBguy]

If you select the Tab control, there is a Click event for it that will fire when you click on the tab area (both on existing and empty tabs). You should be able to determine which one is the Active tab from there. Hope that helps...

 

[MajP]

I stand corrected. Use the tab controls double click and not the page double click. The tab control double click will work on the "tab" area where the page dc works only below the "tab" area. However those events also work inside the page.
If you want to limit it to only the little "tab" area. Then it is back to a transparent control.

 

[MajP]

See if this gives the affect you want.
Only can double click on the tab and not the page. If the page is fine then simply use the tab double click.

 

[Pat Hartman]

I agree that using the double-click for a tab page is non-standard and I don't recommend it. I've never used an interface where you double-clicked on a tab. Tabs function using single clicks.

That said, you might want do download the database I built to demonstrate form/control events. None of the forms in the example have a tab control so you will need to add your own form. Watch at least one of the videos so you can see the way my demo works to display the events that get fired for the forms/subforms I included. You just add your own form. Open my display the events form first. Then open your form and your form's events show up in the display form as they fire. Notice that none of the mouse move events include the logging code. They fire way too frequently and so hide all the other event data. If you actually want to test mouse move events, then add the logging code to those events.

I started out to make a video demonstrating why you should use the form (and sometimes the control's) BeforeUpdate event for validation if you want to ensure that "bad data" doesn't get saved. In the process, I realized that the form I built to display the events was an excellent way to understand how the event model works. All you need to do is to put the one line of code that calls the eventlog into any event where you want to show it if it fires as the first line of code. Then if you want other code in the event, just put it after the log event call.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk

 

[riktek]

I think you are stuck with putting a transparent control there. You can try a command button (transparent, no caption, no border).
Out of curiosity what does it do. You say "obvious click target", but I cannot think of any time I would want to double click the tab.
If you do not like the effect that way you could set the tab control to no tabs, and then place your own labels or buttons above the tab. Then you can do things like color them too.

Thanks. A transparent command button would seem to be the extent of available solutions, or perhaps relying on TabControl.DblClick and clicking in the space unoccupied by the tabs.

To your question, "why do it?", the idea is to have a generalized behavior such that the double-click on an active tab conditionally initiates a nav procedure. So, for example, if a tab page contains a single subform, then double-clicking the tab would open the subform's corresponding main form (meaning the one with the same RecordSource), probably closing the original main form to conserve database instances.

My apps already have standardized nav behavior for text boxes and combo boxes, implemented via an object wrapper (subclass) framework and a rigorous naming convention. This typically takes one either to a specific record on another form, or to the relevant form in continuous-forms view for further navigation, depending on context. Love it or hate it, it removes a great deal of friction for a user and the implementation makes it consistent across an app.

In the context of tab controls, I don't yet have a standard way to navigate to a subform's corresponding main form. Double-clicking on the active tab seems like an intuitive trigger but that area apparently can't respond when the tab is active. Of course, it responds to a click when inactive, making it the active tab, but not otherwise.

The chief drawback of the transparent command button approach is that it doesn't generalize but instead depends on a form-specific configuration. The only generalized behavior is clicking on vacant space in the tab row.

 

[isladogs]

I stopped using tab control some time ago due to various issue.
I now use an 'emulated' tab control consisting of a number of toggle buttons arranged horizontally and a subform whose source object changes according to the toggle button (tab) clicked

Effectively, its a home-grown navigation control without the layout guides.
Easy to create & works perfectly

 

[riktek]

According to the linked article below, a tab control's double-click event exists. It would be subject to the same rules as other click and double-click events for the more common control types.

If your double-click doesn't appear to work, some questions come to mind.

First, do other double-click events work normally for controls that are on that form and NOT associated with a tab-control?

Second, when you double-click that tab control, does it seem that at least a single-click event fires? Or do you get nothing?

Third, does any message appear when you try to click or double-click the tab control?

Thanks. I'm familiar with the object model. Double-click events occur for all objects and work normally.

No Click event occurs for the tab control when clicking on either the tab itself (whether active or not) or in the vacant area of the tab row.

The DblClick event does not occur when done on the tab itself (whether active or not) but does occur when done in the vacant area of the tab row.

No messages are thrown in the app and the error handlers for the event procedures trap nothing.

The only difficulty seems to be that that one particular area (the tab itself) is unresponsive to double-clicks.

 

[riktek]

If you select the Tab control, there is a Click event for it that will fire when you click on the tab area (both on existing and empty tabs). You should be able to determine which one is the Active tab from there. Hope that helps...

Somehow, I can't get the Click event to fire at all. DblClick fires when done on the vacant portion of the tab row.

 

[MajP]

Although you might think it is intuitive double clicking a tab control and launching another form based on the content on the selected tab, I am not sure if many others would agree. But that is your choice. To me to it would be like my wife (an Appple user) asking me to fix her phone and she explains how intuitive it is. All you have to is use three fingers, depress the volume up, swipe up once and down twice and it shows exactly what you expect. Its obvious.
But if it makes sense to you have at it, UI is not really my thing.

Again you can do what @isladogs shows or use a tab control and set the tab format to "None". Then roll your own command buttons or labels.
You can then build a class to handle the events of these pseudo tab buttons. This would control the navigation, formatting when selected, and allow for the double click. It would be then simply a matter of initializing these pseudo tabs.
Or a simple solution would be to create a button maybe a magnifying glass. Instead of embedding into one of the pages put it in the upper right corner over the page. If you "float" it, it would appear as if it is on all pages. Then simply fire the event and determine which page is active. Then you can have a single select case to do stuff.

 

[riktek]

I stopped using tab control some time ago due to various issue.
I now use an 'emulated' tab control consisting of a number of toggle buttons arranged horizontally and a subform whose source object changes according to the toggle button (tab) clicked

View attachment 118138
Effectively, its a home-grown navigation control without the layout guides.
Easy to create & works perfectly

Colin, I've always found you to be quite clever and this approach makes a great deal of sense for many reasons. Throw in some anchoring and resizing and even more so. I'll need to re-engineer how I re-set the link fields properties after Access reconfigures them sui generis when the source object is set in some cases (I currently keep that data in SubForm.Tag) but that shouldn't be insuperable. Thanks.

 

[riktek]

Although you might think it is intuitive double clicking a tab control and launching another form based on the content on the selected tab, I am not sure if many others would agree. But that is your choice. To me to it would be like my wife (an Appple user) asking me to fix her phone and she explains how intuitive it is. All you have to is use three fingers, depress the volume up, swipe up once and down twice and it shows exactly what you expect. Its obvious.
But if it makes sense to you have at it, UI is not really my thing.

Again you can do what @isladogs shows or use a tab control and set the tab format to "None". Then roll your own command buttons or labels.
You can then build a class to handle the events of these pseudo tab buttons. This would control the navigation, formatting when selected, and allow for the double click. It would be then simply a matter of initializing these pseudo tabs.
Or a simple solution would be to create a button maybe a magnifying glass. Instead of embedding into one of the pages put it in the upper right corner over the page. If you "float" it, it would appear as if it is on all pages. Then simply fire the event and determine which page is active. Then you can have a single select case to do stuff.

There definitely are several ways to skin this cat. Most are form-specific, which I'd like to avoid if possible.

Intuitiveness, if that's a word, definitely is in the eye of the beholder. Getting one's head into the Apple UI metaphor (or GNOME, for that matter) helps a great deal and not understanding that can get in the way. To a certain extent, that's also the case here. One can quibble with the notion of a tab double-click ("but that just isn't DONE") but my apps have double-click nav functionality largely throughout, in many contexts. A user familiar with that likely wouldn't find it odd or inconsistent. I'll grant that most still probably wouldn't figure out this particular feature on their own. That's largely beside the point, however.

Or points, I should say. The first is that the Access UI is inconsistent. There is, essentially, an unresponsive hole in the control and the window employed to implement it. The second is that the user who needs to accomplish this particular navigation often enough would find it quite helpful to have. They might not intuit it immediately but once aware would know that forms application-wide behave consistently with this simple interaction. What's less intuitive is that the hole in the control exists. That prevents, or at least inhibits, such development.

 

[MajP]

Again to each their own on user interface but to me this is very simple, takes up little space, and to me pretty intuitive.
Make a single search button and put it on "over" your tab not in a page. Then it appears as if it is on each page, but it is a single button.
Then simply do a select case for each page. Since most likely you are doing slightly different things depending on which page selected.
Also since there is just one button it appears exactly in the same place on each page.

Private Sub cmdTabNav_DblClick(Cancel As Integer)
  Select Case Me.tbCtrl1
  Case 0
    MsgBox "Nav for Page: " & Me.tbCtrl1.Pages(Me.tbCtrl1).Caption
  Case 1
    MsgBox "Nav for Page: " & Me.tbCtrl1.Pages(Me.tbCtrl1).Caption
  Case 2
    MsgBox "Nav for Page: " & Me.tbCtrl1.Pages(Me.tbCtrl1).Caption
  Case 3
    MsgBox "Nav for Page: " & Me.tbCtrl1.Pages(Me.tbCtrl1).Caption
  Case 4
   MsgBox "Nav for Page: " & Me.tbCtrl1.Pages(Me.tbCtrl1).Caption
  End Select
End Sub

 

[MajP]

Here are some other weird tab ideas. Tabs on right, colored tabs, fitted tabs, index card tabs. Most of these were asks from other people to demo ideas.
I found to get fake the tabs with labels required a lot of formatting, so I do the positioning, sizing, and formatting in code.