Version Control for MS Access: Using the MSAccess-VCS Add-in

[KitaYama]

Maybe it gives you a better idea of the situation to investigate.

PowerShell's response to :

[System.Text.Encoding]::Default

 

[KitaYama]

Some insights from our IT:

Even though two PCs have the same code page set to 932 (Japanese, Shift-JIS), the font used in VBA's Immediate window or text controls might be different depending on:

1. Windows display language and regional settings
   This affects the default UI font, and possibly the font fallback behavior for Unicode characters.
2. Installed fonts and font substitutions
   On a PC one might be using a font like MS Gothic, Yu Gothic, or Meiryo, which tend to render … as midline dots.
   On another system, even with CodePage 932 set, Windows might still prefer something like Segoe UI, Arial, or Tahoma, which can render … differently — often bottom-aligned like periods.
3. Font fallback/resolution behavior in legacy apps
   VBA and many older apps use GDI-based rendering, which is sensitive to locale settings and doesn't always treat Unicode consistently across locales.

Unicode is Universal.
Fonts Are Not​

• ChrW(8230) means “horizontal ellipsis”, and that's universal.
• But what font is used to draw it, and how that font's glyph looks, is not universal.

additional info:
I changed my VBE font to "Segoe UI Black (Western)"

Now it's what I have:

IF I change VBE's font to my previous situation (Meiryo UI (Japanese)), I have the same three dots middle line aligned

I assume the developer may want to only add three dots to be sure no error occurs in different situations.

 

[sonic8]

Not that it's that important, but ChrW(8230) is middle aligned, while dot is bottom aligned.
I really don't know which one is correct.

The VBA environment is not suitable to display Unicode characters, which are not included in your current character set (ANSI codepage). - From your original problem with the three-dot-character we know that it is not included in your codepage.

Shouldn't Unicode look the same everywhere?

Not exactly. The core characteristics should be the same but the exact visual appearance depends on the font used to display the characters. However this should not be the problem here, as explained above.

 

[KitaYama]

but the exact visual appearance depends on the font used to display the characters.

That's the exact thing our IT explained. (#22)
Thanks for confirming.

 

[AHeyne]

Thats what ChatGPT says about:

1.​

In Western writing systems (like Latin), punctuation marks such as the ellipsis are typically aligned to the baseline, meaning they appear at the bottom of the text line.


In Japanese typography, especially with proportional or monospaced CJK fonts, punctuation like the horizontal ellipsis is usually centered vertically within the character’s square space. This ensures proper rendering in both horizontal and vertical writing modes, which are common in Japanese texts.


As a result, the ellipsis appears higher compared to how it’s positioned in Western fonts — but that’s actually the typographically correct placement in CJK contexts.

---

2.​

The encoding (like Shift-JIS) only determines which Unicode code point a sequence of bytes refers to. It does not define how the character looks on screen.


Instead, the font you’re using is what controls the visual appearance of the character.


CJK fonts such as MS Gothic, MS Mincho, Meiryo, or Yu Gothic are specifically designed for Japanese text. These fonts render U+2026 (horizontal ellipsis) so that it appears vertically centered, which matches Japanese typographic conventions.

 

[Josef P.]

Thanks for doing the research.

I now have a guess as to why the horizontal ellipsis is used instead of the three dots.
These are not displayed in the ribbon.
However, if you enter "Build As... " (with a space at the end), the three dots are visible.


Which font is used for the ribbon? The font set in the VBE should not matter.

/edit:
By the way, it is due to Access and/or the ribbon that the 3 ending dots are not displayed.
I was able to reproduce the behavior with a static ribbon XML.

<customUI xmlns="http://schemas.microsoft.com/office/2009/07/customui"><ribbon startFromScratch="false">
<tabs><tab id="TestTab1" label="TestTab123">
<group id="TestGroup1" label="Group..." >
<button id="TestButton1" label="Button1..." size="large" onAction="=Msgbox('Button1...')" />
<button id="TestButton2" label="Button2... " size="large" onAction="=Msgbox('Button2...')" />
</group></tab></tabs></ribbon></customUI>

 

[KitaYama]

Which font is used for the ribbon?

From Our IT:

On Windows 11, the font used in the Office ribbon UI (like in Word, Excel, PowerPoint) is generally:
Segoe UI Variable

It can be changed in;
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes

They have doubt about the exact registry key and they have to test to give a solid answer.
They also don't recommend it because this can break Windows UI elements, including file dialogs, taskbar, etc. Not worth it unless I'm very comfortable with system tweaks and backups.

I'm waiting for the result of their tests.
But they warned me it may take a while.

 

[KitaYama]

@Josef P. I have a strange problem with the new version of VCS addin.
I don't remember having this problem with previous version (I may be wrong though. not sure). What I'm sure about is that I have never noticed it.

Some of my apps have a USysRibbons table and the ribbon is added there. These apps have no problem with VCS.
In other cases, I have to add the ribbon dynamically, based on a lot of situations.
In these apps, I create the XML and then set the app's ribbon by:
Application.LoadCustomUI "AppRibbon", strRibbon

When I open any of these apps, at first I have the "Version Control" tab. But as soon as I click any button on "Version Control" tab, the add-in tab disappears. The task of clicked button finishes successfully, but the tab simply is not there anymore.
If I restart the app, the tab comes back to life. But the same problem insists again.

Here's a gif, if I'm not clear.

• I've tested this on 3 PCs, the same result.
• In both types of my apps, ribbon's startFromScratch is set to true.
• If you think it's something related to my specific case (local, language, etc), no need to waste your time to find why it happens. I can live with it.
• A database that shows the situation (for me), is attached. Again, If you don't have the same problem, ignore this post. Don't put your time to find the problem. There's a good chance something's wrong with my PCs.
• Current VCS version : 4.1.2
• Microsoft 365, Windows 11

Thanks.

 

[Josef P.]

I can reproduce the problem with your DB.

In both types of my apps, ribbon's startFromScratch is set to true.

This is the problem.

Problem in the code: clsTranslation.LoadLanguage

    If RibbonLoaded Then
        ' Export strings to json file for use in the ribbon.
        strPath = GetInstallSettings.strInstallFolder & PathSep & "Ribbon.json"
        WriteFile ConvertToJson(GetRibbonStrings, 2), strPath
        modCOMAddIn.ReloadRibbon '<-----
    End If

This is called several times unnecessarily.

But are you developing your application with the hidden ribbon tabs?

Note: Please report bugs/problems as an issue in GitHub: https://github.com/joyfullservice/msaccess-vcs-addin/issues

 

[KitaYama]

But are you developing your application with the hidden ribbon tabs?

Yes. Tabs, Groups, buttons, combos etc would be hidden/disabled for different users with different permissions.

 

[sonic8]

Tabs, Groups, buttons, combos etc would be hidden/disabled for different users with different permissions.

I think, @Josef P. was asking whether you hide ribbon tabs while you are developing the application.

If your approach to hiding the ribbons tabs is "Hide everything, then show what the current user has permission for.", then it appears likely that you yourself are hiding the missing VCS tab.

 

[KitaYama]

I think, @Josef P. was asking whether you hide ribbon tabs while you are developing the application.

Yes I do. I don't use Access default ribbon at all.
OK, I admit it.
It may seem to be strange, but Access default ribbon has nothing special (for me).
I normally login to an account with full permission over db for developing. Just the same way any user logs in to use the database. The login process, adds a ribbon, along with two specail tabs for admin.
"Design" tab is equipped with all the tools I need for designing froms/reports, such as align, size, font, etc
"Admin" tab is equipped with a set of tools for controling App settings, user previllages, structure of ribbon, etc.
BE is sql server and all those sections for relationship, table structure, .... is useless.

The context menu for forms and reports are created during login too. But if an admin (me) logs in, additional buttons are added to the context menus too. (Design , layout, ......)

During developing, I can simply switch between different users and test the new features. A button on admin tab will lock the app, creates a accde and issues a new version.

As you and joseph mentioned, I think startFromScratch=true is the problem.
I think I will shift+double click the db to bypass login procesdure and use Version Control tab when needed.

Thanks to both.

 

[Josef P.]

This is a strange behavior of Access if set startFromScratch="true". (Tested with Version 2503.)
When a COM add-in (with ribbon) is unloaded, all (?) ribbons of COM add-ins disappear.

This must be a feature

 

[sonic8]

This is a strange behavior of Access if set startFromScratch="true". (Tested with Version 2503.)
When a COM add-in (with ribbon) is unloaded, all (?) ribbons of COM add-ins disappear.

I would guess, (un)loading a COM add-in will trigger Access to reload/reprocess the ribbon XML. - If this is true, the behavior is more or less logical. The only potentially surprising "feature" is that the ribbon XML of the current database is (re)processed last.

With startFromScratch="true" you tell Access remove all existing elements from the ribbon. - You see the effect already when you open a database with a startFromScratch-Ribbon.
When you open the database file directly, the startFromScratch-Ribbon is processed first and the ribbon XML of any COM add-in later. => COM add-in Ribbons are visible
When you open Access directly, the ribbon XML of any COM add-in is processed and visible. Then open a database file with a startFromScratch-Ribbon. Access will throw away all existing ribbon elements and COM add-in Ribbons are NOT visible.

 

[Josef P.]

I would guess, (un)loading a COM add-in will trigger Access to reload/reprocess the ribbon XML. - If this is true, the behavior is more or less logical.

The watched behavior would confirm this.

 

[KitaYama]

I just noticed something that partially solves my problem and thought it's worth mentioning here.

This is a part of my ribbon :
<group idMso='GroupAddins' getVisible='GetVisible' />

In a PC with VCS add-in not installed, it shows like this:

Which is normal.
In a Pc with VCS installed, it shows like this:

So, even if the tab goes invisible, I can use it through this menu.

 

[Josef P.]

Alternative:
If you remove the line modCOMAddIn.ReloadRibbon in the LoadLanguage procedure of the clsTranslation class, the COM add-in will not be unloaded and the ribbon will not disappear.

The add-in is unloaded/loaded too often.
I would change it like this:

Private Sub LoadLanguage(strLanguage As String, Optional ByVal ReloadRibbonIfLoaded As Boolean = False)

    ....

    ' Reload the ribbon to reflect any translation changes there.
    If ReloadRibbonIfLoaded Then  '<--- New
        If RibbonLoaded Then
            ' Export strings to json file for use in the ribbon.
            strPath = GetInstallSettings.strInstallFolder & PathSep & "Ribbon.json"
            WriteFile ConvertToJson(GetRibbonStrings, 2), strPath
            modCOMAddIn.ReloadRibbon
        End If
    End If

End Sub

... and only set the ReloadRibbonIfLoaded parameter to True if the language has been changed.

 

[Josef P.]

Since I believe that the COM add-in is being unnecessarily reloaded every time clsTranslation is instantiated, I created a GitHub issue to track the problem: https://github.com/joyfullservice/msaccess-vcs-addin/issues/622