Is there a way to make the multiple tab rows not move?

[Guest]

MS Access 2K, Windows XP
=====================
Hi,

The database I'm working with has forms with the tab pages displayed in 2
rows. When a tab page in the top row is clicked to bring it to the front, the
top row also moves to the bottom. The feedback from users is that this is a
very irritating and confusing behavior, and I agree.

Is there a way to stop this from happening, so that the tab rows are "fixed"
and do not move when a tab-page in the top row is clicked?

Thanks.

-Amit

 

[Rick B]

I don't know if you can change that or not, but the behavior you describe is
consistent with Microsoft products. Go to the MS Word "Tools" menu and
select "Options" to see an example.

Personally, I don't try to modify Windows standard features when I build
databases because it will confuse the folks who know the standards.

Just my opinion.

Rick B

 

[Guest]

Personally, I don't try to modify Windows standard features when I build
databases because it will confuse the folks who know the standards.

I agree with you on this, but some of the MS behavior does make me go "What
were they thinking?". It seems that _some_ of their "features" are more of a
pain in the a&& than making life easier for the user. Oh well.

I actually figured out a way by changing the TabControl Style to "Buttons"
instead of "Tabs". That way, the "buttons" stay at their place and don't move
around when clicked.

Thanks for your response Rick.

-Amit

 

[Rick Brandt]

I agree with you on this, but some of the MS behavior does make me go
"What were they thinking?". It seems that _some_ of their "features"
are more of a pain in the a&& than making life easier for the user.
Oh well.

I actually figured out a way by changing the TabControl Style to
"Buttons" instead of "Tabs". That way, the "buttons" stay at their
place and don't move around when clicked.

Thanks for your response Rick.

If you left the type as "Tabs" instead of buttons what would indicate the
currently selected tab if it were not moved to the front?

 

[Rob Oldfield]

Good point. To expand a touch... if you had a top row of two tabs and a
second row of three, then the 'keep it in the same position' argument would
mean that selecting the second tab on the top row would completely
obliterate the right hand tab on the second row.

 

[Guest]

If you left the type as "Tabs" instead of buttons what would indicate the

currently selected tab if it were not moved to the front?

Excellent point. I didn't think of it that way. But, wouldn't changing the
color of the active tab take care of that without the confusion of moving the
rows?

-Amit

 

[Guest]

Good point. To expand a touch... if you had a top row of two tabs and a
second row of three, then the 'keep it in the same position' argument would
mean that selecting the second tab on the top row would completely
obliterate the right hand tab on the second row.

Yup. I see your point. Hey, at least MS gave the option of "buttons" on a
tabControl for users who find the "moving rows" feature confusing to use

-Amit

 

[Marshall Barton]

Excellent point. I didn't think of it that way. But, wouldn't changing the
color of the active tab take care of that without the confusion of moving the
rows?

Color would do that - for those of us with good vision.

Besides using buttons, there is another thing you could do.
Set the tab control's tab style to None, and use whatever
mechanism you like (Combo box, Option Group, etc) to select
a tab page. Use the selector control's AfterUpdate event to
set the tab control's Value property.

 

[Rick Brandt]

Excellent point. I didn't think of it that way. But, wouldn't
changing the color of the active tab take care of that without the
confusion of moving the rows?

-Amit

The TabControl originated from the desire to graphically emulate a rolodex
of tabbed cards. The selected card is always the one in the front. One can
certainly argue that the way a multi-row tab control works is not optimum in
terms of user-friendliness, but I don't think you can make the argument that
the way it works is "not expected".

I simply avoid TabControls that will have multiple rows and when I
absolutely need more tabs than can fit on a single row I don't use the {Tab}
style.

 

[Guest]

The TabControl originated from the desire to graphically emulate a rolodex
of tabbed cards. The selected card is always the one in the front. One can
certainly argue that the way a multi-row tab control works is not optimum in
terms of user-friendliness, but I don't think you can make the argument that
the way it works is "not expected".

Oh, I do agree that it works the way it is supposed to work. I wasn't sure
about the reason for that, but your earlier post made me realize that it does
make sense. From my experience and other users, I find that the behavior is
confusing and not very user-friendly. IMO, it is one of those features that
one has to learn to use/get used to.

I simply avoid TabControls that will have multiple rows and when I
absolutely need more tabs than can fit on a single row I don't use the {Tab}
style.

How do you accomplish that? I initially started with single row, but the
users complained that they wanted to see all the tabs on the same page
instead of scrolling. So, I changed it to multiple row, and faced a new
problem

Thanks.

-Amit

 

[Rick Brandt]

Oh, I do agree that it works the way it is supposed to work. I wasn't
sure about the reason for that, but your earlier post made me realize
that it does make sense. From my experience and other users, I find
that the behavior is confusing and not very user-friendly. IMO, it is
one of those features that one has to learn to use/get used to.


How do you accomplish that? I initially started with single row, but
the users complained that they wanted to see all the tabs on the same
page instead of scrolling. So, I changed it to multiple row, and
faced a new problem

As stated in other posts, I either use the Buttons style or (more often) the
style of "None" and control which page is displayed with a ListBox or
ComboBox or my own buttons.