Of tabs and pages

I'm having trouble sorting out some things involving tabs and pages in a tab
control. From what I can tell, the tab control can contain several
individual tabs, each of which is a page. A page seems to be something like
a tab control's version of a Detail section.

Here's the part where it gets mysterious. I used message boxes to test the
click event for the tab control, the page, and the detail section (msgbox
"Tab Control", etc.). The page's Click event occurs whenever I click a
blank space on the page, unless I click the actual tab, in which case
nothing seems to happen. If I click the very edge of the page, or to the
right of the rightmost tab control, the tab control's Click event runs. If
I click beside or below the tab control, the detail section's Click event
runs. The things I can't figure are why the tab control even has a Click
event, since clicking it is a bit of a trick; and why a Click event
apparently can't be associated with the tab itself, which is the thing most
likely to be clicked. I can probably simulate a tab click event with a Got
Focus event for a control or something like that, but it seems roundabout.

The lack of formatting options for caption text color, page background
color, and so forth is a bit annoying. I know about Lebans' system for
changing background color and so forth, but I haven't been able to figure it
out yet. I'm not too concerned about the format, and can only hope that the
powers that be within my company feel the same way. Functionality comes
first, and there is still work to do on that. The question arose because I
realized during development that a tabbed form would work better than a
one-page form. Clicking a tab is often preferable to scrolling, I think.

Bruce

Have you tried using the OnChange event?

--
Regards

Jeff Boyce
Microsoft Office/Access MVP
http://mvp.support.microsoft.com/

Microsoft IT Academy Program Mentor
http://microsoftitacademy.com/

Microsoft Registered Partner
https://partner.microsoft.com/


"BruceM" wrote in message
...
I'm having trouble sorting out some things involving tabs and pages in a
tab
control. From what I can tell, the tab control can contain several
individual tabs, each of which is a page. A page seems to be something
like
a tab control's version of a Detail section.

Here's the part where it gets mysterious. I used message boxes to test
the
click event for the tab control, the page, and the detail section (msgbox
"Tab Control", etc.). The page's Click event occurs whenever I click a
blank space on the page, unless I click the actual tab, in which case
nothing seems to happen. If I click the very edge of the page, or to the
right of the rightmost tab control, the tab control's Click event runs.
If
I click beside or below the tab control, the detail section's Click event
runs. The things I can't figure are why the tab control even has a Click
event, since clicking it is a bit of a trick; and why a Click event
apparently can't be associated with the tab itself, which is the thing
most
likely to be clicked. I can probably simulate a tab click event with a
Got
Focus event for a control or something like that, but it seems roundabout.

The lack of formatting options for caption text color, page background
color, and so forth is a bit annoying. I know about Lebans' system for
changing background color and so forth, but I haven't been able to figure
it
out yet. I'm not too concerned about the format, and can only hope that
the
powers that be within my company feel the same way. Functionality comes
first, and there is still work to do on that. The question arose because
I
realized during development that a tabbed form would work better than a
one-page form. Clicking a tab is often preferable to scrolling, I think.

No, I hadn't tried the tab control's OnChange event, since the description
is that it runs when the data changes. Maybe I'm taking "data change" in a
different sense than is used in the description (I would have thought it
means when the data, not the focus, changes), but it does indeed run
whenever I go to another tab. Thanks for the tip.
I'm still puzzled by the tab control's Click event, which seems quite
limited, but maybe there is a situation I can't picture in which it makes
sense. This is really just a comment, not a request for a reply. Thanks
for your help.

"Jeff Boyce" -DISCARD_HYPHEN_TO_END wrote in message
...
Bruce

Have you tried using the OnChange event?

--
Regards

Jeff Boyce
Microsoft Office/Access MVP
http://mvp.support.microsoft.com/

Microsoft IT Academy Program Mentor
http://microsoftitacademy.com/

Microsoft Registered Partner
https://partner.microsoft.com/


"BruceM" wrote in message
...
I'm having trouble sorting out some things involving tabs and pages in a
tab
control. From what I can tell, the tab control can contain several
individual tabs, each of which is a page. A page seems to be something
like
a tab control's version of a Detail section.

Here's the part where it gets mysterious. I used message boxes to test
the
click event for the tab control, the page, and the detail section (msgbox
"Tab Control", etc.). The page's Click event occurs whenever I click a
blank space on the page, unless I click the actual tab, in which case
nothing seems to happen. If I click the very edge of the page, or to the
right of the rightmost tab control, the tab control's Click event runs.
If
I click beside or below the tab control, the detail section's Click event
runs. The things I can't figure are why the tab control even has a Click
event, since clicking it is a bit of a trick; and why a Click event
apparently can't be associated with the tab itself, which is the thing
most
likely to be clicked. I can probably simulate a tab click event with a
Got
Focus event for a control or something like that, but it seems
roundabout.

The lack of formatting options for caption text color, page background
color, and so forth is a bit annoying. I know about Lebans' system for
changing background color and so forth, but I haven't been able to figure
it
out yet. I'm not too concerned about the format, and can only hope that
the
powers that be within my company feel the same way. Functionality comes
first, and there is still work to do on that. The question arose because
I
realized during development that a tabbed form would work better than a
one-page form. Clicking a tab is often preferable to scrolling, I think.

BruceM wrote:
No, I hadn't tried the tab control's OnChange event, since the
description is that it runs when the data changes. Maybe I'm taking
"data change" in a different sense than is used in the description (I
would have thought it means when the data, not the focus, changes),
but it does indeed run whenever I go to another tab. Thanks for the
tip. I'm still puzzled by the tab control's Click event, which seems quite
limited, but maybe there is a situation I can't picture in which it
makes sense. This is really just a comment, not a request for a
reply. Thanks for your help.

The TabControl has a Value property which takes on the Index property of
whichever page is currently selected. So when you change TabPages the
"Value" of the TabControl does change. It is not really "data", but it is a
value change nonetheless.

The click event of a TabPage works exactly as expected once you realize that
the "tab" is not considered to be part of the TabPage. That is why clicking
on the "tab" does not trigger the click event for that page. The event only
fires when you click on the background of the page itself, just like the
click event of a form section. It is mostly useless.


--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Thanks for the explanation about the Value property. Now it makes some
sense that the event runs. I see that the tab itself is not part of the tab
control, but it doesn't seem to be part of the page either. In fact, it
seems to be one of the very few places without a Click event.
You have confirmed what I suspected about the general uselessness of the tab
control's Click event. I have been known to use things such as a label's
double-click event to give myself a hidden way to unlock a locked text box
or something of the sort. I guess the tab control's double-click event
could serve the same purpose. Still, it seems to be in the same general
category as the SysRq key.

"Rick Brandt" wrote in message
t...
BruceM wrote:
No, I hadn't tried the tab control's OnChange event, since the
description is that it runs when the data changes. Maybe I'm taking
"data change" in a different sense than is used in the description (I
would have thought it means when the data, not the focus, changes),
but it does indeed run whenever I go to another tab. Thanks for the
tip. I'm still puzzled by the tab control's Click event, which seems
quite
limited, but maybe there is a situation I can't picture in which it
makes sense. This is really just a comment, not a request for a
reply. Thanks for your help.

The TabControl has a Value property which takes on the Index property of
whichever page is currently selected. So when you change TabPages the
"Value" of the TabControl does change. It is not really "data", but it is
a value change nonetheless.

The click event of a TabPage works exactly as expected once you realize
that the "tab" is not considered to be part of the TabPage. That is why
clicking on the "tab" does not trigger the click event for that page. The
event only fires when you click on the background of the page itself, just
like the click event of a form section. It is mostly useless.


--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

BruceM wrote:
Thanks for the explanation about the Value property. Now it makes
some sense that the event runs. I see that the tab itself is not
part of the tab control, but it doesn't seem to be part of the page
either.

That is what I wrote. It is not part of the TabPage.

In fact, it seems to be one of the very few places without a
Click event.

Exactly.

You have confirmed what I suspected about the general uselessness of
the tab control's Click event.

The TabControl does not have a click event. The individual pages do and yes,
it is mostly useless.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

"Rick Brandt" wrote in message
...
BruceM wrote:
Thanks for the explanation about the Value property. Now it makes
some sense that the event runs. I see that the tab itself is not
part of the tab control, but it doesn't seem to be part of the page
either.

That is what I wrote. It is not part of the TabPage.

In fact, it seems to be one of the very few places without a
Click event.

Exactly.

You have confirmed what I suspected about the general uselessness of
the tab control's Click event.

The TabControl does not have a click event. The individual pages do and
yes, it is mostly useless.

I can only address Access 2003, but if I select the tab control and click
View Properties, it has a Click event (and Double-click, mouse move, key
down, and other events that I might classify as I/O device events).

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

"BruceM" wrote in message
...

"Rick Brandt" wrote in message
...
BruceM wrote:
Thanks for the explanation about the Value property. Now it makes
some sense that the event runs. I see that the tab itself is not
part of the tab control, but it doesn't seem to be part of the page
either.

That is what I wrote. It is not part of the TabPage.

In fact, it seems to be one of the very few places without a
Click event.

Exactly.

You have confirmed what I suspected about the general uselessness of
the tab control's Click event.

The TabControl does not have a click event. The individual pages do and yes,
it is mostly useless.

I can only address Access 2003, but if I select the tab control and click View
Properties, it has a Click event (and Double-click, mouse move, key down,
and other events that I might classify as I/O device events).

Ah, so it does. That would appear to be even more useless than the click event
for a page as you can only get it to fire by clicking the edge of the control or
in the area to the right of the tabs.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com