VBE custom code colors (syntax highlighting)

[AHeyne]

I'm just wondering that here in the forum the topic of custom code colors in the VBE is not so widespread.

I can't imagine for the life of me to code with the default colors of the VBE anymore.

First a small digression to the topic "VBEThemeColorEditor":​

In the past years, I still consciously developed with Microsoft Access 2013 (MSI setup).

There I used the VBEThemeColorEditor (https://github.com/gallaux/VBEThemeColorEditor) to patch my desired colors into the "Vbe7.dll" to be able to create a Monokai-like scheme.

However, this procedure also had disadvantages:
- After patching the DLL, Microsoft Access always crashed when I activated the "Editor Format" tab in the VBE under "Tools / Options".
But I was able to fix that, as discussed here: https://github.com/gallaux/VBEThemeColorEditor/issues/11.
- If Microsoft made changes to the DLL by an update, I had to patch the new version again accordingly. But even that worked.
- However, since I switched to Microsoft Access 2016 (C2R setup) due to Microsoft's lack of further support for Microsoft Access 2013, Microsoft quite often replaces my patched DLL with the original version. And I have to copy my patched version back into the appropriate folder. This is annoying.

Now to the actual topic:​

So I looked to see if I couldn't get something reasonably maybe Monokai-like with the original colors, where I don't have to patch the DLL at all, but use the original version.

The result is this color and font configuration:

I'm more than happy with this.

Who wants to try it can import this registry file:

```
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\VBA\7.1\Common]
"FontHeight"=dword:0000000c
"FontCharSet"=dword:00000000
"FontFace"="Consolas"
"CodeBackColors"="4 3 4 7 6 4 4 4 0 0 0 0 0 0 0 0 "
"CodeForeColors"="8 1 5 4 1 3 2 12 0 0 0 0 0 0 0 0 "
"CodeBackColorsOriginal"="0 0 0 7 6 0 0 0 0 0 0 0 0 0 0 0 "
"CodeForeColorsOriginal"="0 0 5 0 1 10 14 0 0 0 0 0 0 0 0 0 "
```

The registry file only changes settings that can be set in the VBE under "Tools / Options" on the "Editor Format" tab, so no 'tricks' are used.

Font name, size, foreground and background colors are set.
The original Microsoft colors are stored in the additional "*Original" values.

If you have already configured your own colors there, you should save them beforehand, e.g. using the registry editor under "HKEY_CURRENT_USER\Software\Microsoft\VBA\7.1\Common".
It is sufficient if you rename the values "CodeForeColors" and "CodeBackColors" to "MyCodeForeColors" and "MyCodeBackColors", then they cannot be overwritten and you can restore them in the registry editor later on if you want.

And of course I'm also very curious to see which colors you have configured in your VBE.

 

[AHeyne]

Another addendum to the topic Indicator Colors.

Unfortunately, the VBE (at least for me) does not save the configured values.

But I found out by trial and error that you can configure them in the registry in the same place.

You have to create a 'REG_SZ' value called "IndicatorColors" with corresponding values (the structure is the same as e.g. "CodeForeColors").

These values will then be read correctly at least when loading the VBE.

I was also able to find out the following information myself:

The default value for the registry value "IndicatorColors" is therefore (with the space at the end)

0 0 0 7 6 0 0 0 11 9 0 0 0 0 0 0

The digits 1-10 of the respective values (11-16 are unused)

| Position | Name                 | Default Color | Default Color Value |
| -------: | :------------------- | :------------ | ------------------: |
|        1 | Normal Text          | Auto          |                   0 |
|        2 | Selection Text       | Auto          |                   0 |
|        3 | Syntax Error Text    | Auto          |                   0 |
|        4 | Execution Point Text | Yellow        |                   7 |
|        5 | Breakpoint Text      | Maroon        |                   6 |
|        6 | Comment Text         | Auto          |                   0 |
|        7 | Keyword Text         | Auto          |                   0 |
|        8 | Identifier Text      | Auto          |                   0 |
|        9 | Bookmark Text        | Aqua          |                  11 |
|       10 | Call Return Text     | BrightGreen   |                   9 |

Color values

| Color value | Name        |
| ----------: | :---------- |
|           0 | Auto        |
|           1 | White       |
|           2 | Silver      |
|           3 | Gray        |
|           4 | Black       |
|           5 | Red         |
|           6 | Maroon      |
|           7 | Yellow      |
|           8 | Olive       |
|           9 | BrightGreen |
|          10 | Green       |
|          11 | Aqua        |
|          12 | Teal        |
|          13 | Blue        |
|          14 | DarkBlue    |
|          15 | Fuchsia     |
|          16 | Violet      |

 

[MsAccessNL]

Thx for the infoI have been experimenting with the gallaux code to. I am currently using a QHD screen and i want to make the font size in the nav pane and in the vbe explorer pane bigger, do you know a hack to do this?

 

[AHeyne]

No, unfortunately not, since I have not had the requirement so far I have never looked for it. I am on 23" with 1920*1200.

 

[Mike Krailo]

Here's the one I use. The font here is Source Code Pro.

 

[sonic8]

- However, since I switched to Microsoft Access 2016 (C2R setup) due to Microsoft's lack of further support for Microsoft Access 2013, Microsoft quite often replaces my patched DLL with the original version. And I have to copy my patched version back into the appropriate folder. This is annoying.

Microsoft does not necessarily redistribute the "original version" of the DLL. It it is probably a new version that includes relevant changes.
So, if you then replace a new version delivered with an Microsoft update with and old, already color-patched version, you combine an old version of the VBE with a new version of Office that was never meant to be run in this combination.

Instead: Apply the color-patch to the new version of VBE that was installed with the update.

 

[AHeyne]

Hi Philipp,
I'm aware of this, that was how I did long time with Access 2013.
But since I switched to Access 2016 the patched DLL will be replaced by the same unpatched binary file which I patched before.
I made backups of the patched DLL and its original and when Microsoft replaced it I compared them binary.
This never happened when I used Access 2013. There it only has been replaced when Microsoft made changes to the dll, so when they released a new version.
I expect that behaviour comes from the C2R environment.

 

[MsAccessNL]

My attention is drawn by the SaveBeforRun setting. Sometimes when I edit my code (without saving) and i run it with an error, the changes are gone, could this be an option that the code is automatically saved before running the code?

 

[Mike Krailo]

Just discovered a nice program that updates our VBE standard editor colors to whatever color we want. This enables a custom themed setup in our VBE's. I knew this was possible, but never had any luck getting it to work. I just tried out VBE_colours and it worked perfectly. Of course, make a backup of your VBA7.1 folder just in case something does go wrong. I still had to make the basic selections in the Options for setting up the VBE colors, but now the pallet is filled with my custom colors.

This is a simple Blue on Charcoal theme I just created:

Here is a light theme based on the Hubspot.com website.

If you receive this error message when applying a custom color scheme that you have saved. Then try logging out and back in, or reboot first. I did have that issue even though I closed all office applications first, it wouldn't switch the theme over until I rebooted and tried again.

 

[Pat Hartman]

My attention is drawn by the SaveBeforRun setting. Sometimes when I edit my code (without saving) and i run it with an error, the changes are gone, could this be an option that the code is automatically saved before running the code?

Changing code while it is running is dangerous at best and loss of the changed code is one of the issues. You should ALWAYS save and compile before continuing to test.

 

[gemma-the-husky]

Changing code while it is running is dangerous at best and loss of the changed code is one of the issues. You should ALWAYS save and compile before continuing to test.

Despite knowing it will happen at inopportune moments, I still get caught by that one from time time to time.

 

[AHeyne]

My attention is drawn by the SaveBeforRun setting. Sometimes when I edit my code (without saving) and i run it with an error, the changes are gone, could this be an option that the code is automatically saved before running the code?

Have you received any further information on this setting? How were your trials?

 

[Pat Hartman]

Have you received any further information on this setting? How were your trials?

You need to test this setting for yourself. Since we don't actually know what causes Access to fail, it is impossible to force the error. I would acquire some discipline and remember to compile and save EVERY time you change code and are ready to test.

 

[Mike Krailo]

Here is another dark theme using the Source Code Pro font.

 

[AHeyne]

You need to test this setting for yourself. Since we don't actually know what causes Access to fail, it is impossible to force the error. I would acquire some discipline and remember to compile and save EVERY time you change code and are ready to test.

Thanks for the answer, I compile and save too often rather than too little and do not have the problem described.
But for the back of my mind, I'm interested to know if there is any insight into the setting mentioned.