Solved Ampersand in Page.Caption Right-Justifies Its Text

[riktek]

@riktek
I can't replicate your issue either with ampersands in tab page captions or even with a form caption in tabbed documents display.
Whatever I try, the captions are always centre aligned:

View attachment 120477

Others in my prior post couldn't either, at first, so no surprise, but then several did.

 

[riktek]

A2007 has been out of support for almost 8 years. There will be no fixes. You will have to upgrade, or live with this.

Tom, as noted in my original post, I reported this previously concerning A2007, it then was confirmed on A2007-A2013, and I now have observed it on A2019, which I'm currently working with.

 

[riktek]

I see it in A2K7

View attachment 120481

Code behind form:

Option Explicit
Option Compare Database

Private Sub Form_Load()
  Call TabsFullWidth
End Sub

Private Function TabsFullWidth() As Boolean

  Const SPACER As Long = 50
 
  With Me.TabCtl0
    .TabFixedWidth = (.Width - SPACER) \ .Pages.Count
  End With
  TabsFullWidth = Err = 0

End Function

Interesting. So, it's confirmed on A2010.

 

[riktek]

PS. Are you using code to hide the ribbon?

Yes, now, but I wasn't in the prior case. Are you aware that this may create a difficulty?

 

[riktek]

It seems this is just one of the many ways that Access has overall improved since the dim and distant days of A2007.
Anyway, I don't know which version of Access that @riktek uses but I can't replicate the issue in the versions I used for testing.

Colin, as noted in my original post, I'm currently on A2019, in which I just now observed the behavior, and previously reported it on A2007, whereupon it was confirmed in A2010-A2013.

 

[isladogs]

Sorry I missed the comment about using A2019. Whilst I don’t have that it’s basically the same code base as 2021/2024 and 365

Someone in the thread at UA suggested that turning themes on fixed the issue. Have you experimented with that? Also just a thought… are you experiencing the issue in .MDB files or files converted from .MDB?

The 2007 ribbon comment by @cheekybuddha was aimed at me. AFAIAA, that isn’t a factor.

It would be helpful if you post a simple repro database for others to test

 

[riktek]

Judging by responses, this seems (as before) to be a transient bug replicatable by some but not others, and in any case without an obvious fix.

I'll try re-developing the form and controls, probably with no code at first, in case design changes corrupted something. I'll report back if I can isolate a trigger.

This also may be a good time to take Colin's lead, ditching the TabControl entirely and substituting labels.

 

[isladogs]

I hadn’t mentioned it in this thread but it is true that I now largely avoid tab controls for various reasons.
These days I use my own home made simulated navigation forms (not the built-in version)

 

[riktek]

Sorry I missed the comment about using A2019. Whilst I don’t have that it’s basically the same code base as 2021/2024 and 365

Someone in the thread at UA suggested that turning themes on fixed the issue. Have you experimented with that?

The 2007 ribbon comment by @cheekybuddha was aimed at me. AFAIAA, that isn’t a factor.

I noted the themes comment yesterday, and no, I haven't tried that yet. I have a few things competing for my attention this instant but will fiddle with that and report back.

I'm actually doing some integration work concerning themes, etc., so this could be a timely wrinkle.

 

[riktek]

I hadn’t mentioned it in this thread but it is true that I now largely avoid tab controls for various reasons.
These days I use my own home made simulated navigation forms (not the built-in version)

I'm noodling a bit on how the labels approach might substitute for a page with many subforms, but that's admittedly a special case.

I have navigation baked into my application framework, that handles moving among forms and records. See here. AutoKeys can be handy to open forms in the first place, and I'm working on extending the concept. Nav forms are behind a few other UI topics on my list because the current implementation handles almost everything, but I, too, have largely ruled out the native objects, for whenever I do get to it.

 

[isladogs]

You can use labels or buttons to simulate tab controls or navigation style forms
The main reason why I moved to the latter is because only one subform is ever loaded at a time whereas with tab controls, all objects are loaded into memory whether or not they are currently displayed
There are other reasons as well e.g. issues with multirow tab control headers:

The Curious Case of the Multirow Tab Control

When you have many tabs on a control, the Multi Row property may seem to be the solution, but it no longer works by default. This article explains how to successfully use the Multi Row property of the Access tab control and suggests several alternatives

isladogs.co.uk

Anyway, I've just converted my test db from post #6 as a .MDB file (so no themes)
Result: tab page captions are no longer centred but I wouldn't say they are right aligned either
Removing the ampersand makes the captions centre aligned (as you pointed out earlier)

Changed the db back to ACCDB with tab control property Use themes = No. Results as above
Repeated with new ACCDB with tab control property Use themes = No. Results as above.

Changed tab control property Use themes to Yes. Captions centred again. You can see the change occur in design view

So I think that confirms beyoned doubt that the issue is due to having the tab control Use themes property = No together with using an ampersand as a shortcut key

 

[riktek]

You can use labels or buttons to simulate tab controls or navigation style forms
The main reason why I moved to the latter is because only one subform is ever loaded at a time whereas with tab controls, all objects are loaded into memory whether or not they are currently displayed
There are other reasons as well e.g. issues with multirow tab control headers:

The Curious Case of the Multirow Tab Control

When you have many tabs on a control, the Multi Row property may seem to be the solution, but it no longer works by default. This article explains how to successfully use the Multi Row property of the Access tab control and suggests several alternatives

isladogs.co.uk

Anyway, I've just converted my test db from post #6 as a .MDB file (so no themes)
Result: tab page captions are no longer centred but I wouldn't say they are right aligned either
Removing the ampersand makes the captions centre aligned (as you pointed out earlier)

View attachment 120494

Changed the db back to ACCDB with tab control property Use themes = No. Results as above
Repeated with new ACCDB with tab control property Use themes = No. Results as above.

Changed tab control property Use themes to Yes. Captions centred again. You can see the change occur in design view

So I think that confirms beyoned doubt that the issue is due to having the tab control Use themes property = No together with using an ampersand as a shortcut key

Quite interesting. You've replicated the behavior exactly, for starters. Agreed that it's not quite right justified. Perhaps better put, the caption text seems to begin at the center (instead of being centered).

Also, it's quite odd that UseThemes should bear on this but who knows.

I do lazy loading in the TabControl wrapper / superclass in my application framework, FWIW, but agreed that the default subform load behavior would be ample reason to avoid (or overhaul) TabControls,

 

[isladogs]

Themes also affect the behaviour of the MultiRow Tab Control Header - see my article linked above for an explanation

 

[tvanstiphout]

Here's the problem case:
View attachment 120492
and here's the case omitting the ampersand for the first (leftmost) tab:
View attachment 120491

I will add that, in my prior post on this topic, many at first could not replicate the issue but then others did, going on to discover it introduced unspecified instabilities.

Very interesting. Thanks for posting.
A few questions. Please answer all of them so we don't have to go back and forth.
What exact version of A2019 are you on (see File > Account)?
What locale are you in? Is this US-English?
What font are you using for your captions? I am surprised to see AllCaps.
Is there any VBA setting or manipulating tab control properties, or is this all done declaratively at design time?
Do you have a Default Printer defined?

 

[riktek]

Very interesting. Thanks for posting.
A few questions. Please answer all of them so we don't have to go back and forth.
What exact version of A2019 are you on (see File > Account)?
What locale are you in? Is this US-English?
What font are you using for your captions? I am surprised to see AllCaps.
Is there any VBA setting or manipulating tab control properties, or is this all done declaratively at design time?
Do you have a Default Printer defined?

In order:
- MSO Professional Plus v2506, build 19825.20138 Click-to-Run
- US-English
- EngraversGothic BT, in which lower case characters seem like small caps.
- I bind tab controls (and other controls) to a control-specific superclass / control wrapper. The tab control wrapper sinks object-specific and form events, chiefly to lazy-load subforms. All subforms are unbound by default, with .SourceObject and link field strings in their respective .Tag properties. When a form opens, it binds itself to the form wrapper, which iterates its controls, binding them to control-specific superclasses, as noted. The tab control class when bound sets some properties (.BackStyle, .BorderStyle, etc.) and iterates controls on the current page. For subform controls, parses .Tag and assigns .SourceObject and the link field properties. Other configuration is static and control-specific.
- The default printer is Microsoft XPS Document Writer.

 

[isladogs]

@riktek
For info, I've just reported this issue to the Access team but I doubt whether it matters enough for them to fix.

As already stated, this is purely a display issue related to the original tab control with no themes.
It looks odd but doesn’t affect functionality. There is also an easy workaround - enable tab themes (this loads the 'new' tab control).

 

[riktek]

@riktek
For info, I've just reported this issue to the Access team but I doubt whether it matters enough for them to fix.

As already stated, this is purely a display issue related to the original tab control with no themes.
It looks odd but doesn’t affect functionality. There is also an easy workaround - enable tab themes (this loads the 'new' tab control).

@isladogs , thanks for your attention and taking the time to report this behavior.

I did tinker with the TabControl.UseTheme property in A2019 and toggling it does indeed toggle the mis-centering bug. Quite odd because no obvious connection or relevance exists other than being in the context of this class/object, but there you have it. So, that's confirmed and thanks for surfacing something that can be done.

I take your point about prioritization but would hasten to add that anything to do with themes, colors, fonts, shades, and tints also is purely a display issue that doesn't affect functionality, or at least not to a greater or lesser extent than does this bug. The latter simply and unavoidably is a failure of the user interface. While the TabControl has evolved to add new properties, it isn't a "new" object in the sense that we now have a "new" Outlook, but rather continues to manifest this failure even in current versions. The workaround also isn't necessarily easy because it may require a substantial overhaul of an application's interface definition scheme, and a review of it in any event. So, I'm less certain that any reason exists to de-prioritize the matter. Indeed, if only out of shame for the failure's persistence and having been known for so long, reason ought to exist to move it up. I don't expect it will be going away otherwise. [I'm not ordinarily this curmudgeonly after coffee. Perhaps my high horse will depart if I go for another cup. Beg pardon.]

Cheers.

 

[isladogs]

I also wrote this up as a new article on my website today:

Tab Control Page Caption Alignment Issue

This article outlines a display issue where tab control page captions may be shifted off-centre where an ampersand is used as a shortcut key.

www.isladogs.co.uk

The priority given to fixing issues depends on the number of users affected and the seriousness of its impact. In this case it almost certainly affects very few users and does not in any way affect functionality. Yes, it looks odd but is purely a display issue.

The reason that I doubt it will get fixed is that there are in fact two versions of the tab control and the vast majority of users probably use the newer default version where Use Theme = Yes.
The older version where Use Theme = No dates back to 2000 or thereabouts and the only obvious reason why anyone would need to choose that is if they want a multirow tab control header which isn't available in the newer control.

The Curious Case of the Multirow Tab Control

When you have many tabs on a control, the Multi Row property may seem to be the solution, but it no longer works by default. This article explains how to successfully use the Multi Row property of the Access tab control and suggests several alternatives

www.isladogs.co.uk

Of course, old MDB databases created in A2003 or earlier only had the old control (with no theme) and would still have this.
However if you convert the file format to ACCDB and later make any change to the controls' appearance (e.g. border colour), Access will automatically change the Use Theme property to Yes which means you are then using the newer control again!

 

[riktek]

I also wrote this up as a new article on my website today

Wow. Thanks for that, too. One often enough is made out to be a fool or incompetent when posting about anomalies (thankfully, not so much in Access-specific fora) and seldom acknowledged.

The priority given to fixing issues depends on the number of users affected and the seriousness of its impact.

I'm not holding my breath.

Pending resolution, it does provide some license for ridicule, however. Not as much as progress with Word catching up to the WordPerfect [5.0 for DOS] Reveal Codes capability, but still.

 

[isladogs]

You're welcome.

I loved the Reveal Codes feature in the old WordPerfect! Ah it was only 35 years ago or thereabouts.