Custom themes not getting restored or set

[A9G-Data-Droid]

While testing the latest version (3.4.1) that has new color sanitize features I noticed that my custom theme colors are not present in the freshly built DB.

To recover I had to open an older version, save the theme as a new custom theme in Access, then open the built DB and set it's theme to my new custom theme.

STEPS TO REPRODUCE:

1. Create a custom theme
2. Apply it to the test DB
3. Use some custom colors on controls
4. Export
5. Delete the custom theme from Access (to simulate a different computer or fresh install)
6. Build the DB from source

EXPECTED BEHAVIOR:
At this point you should have your custom theme restored and it should be the official theme for the built DB. Your custom control colors should be visible.

[joyfullservice]

Thanks for reporting this! We definitely want custom themes restored as part of the build process.

[hecon5]

Can confirm, this happens tk me, too

[hecon5]

@A9G-Data-Droid, I also noticed recently that the theme exported also has two other theme files exported lately, usually "_1" and "_2".

[joyfullservice]

Note that you must restart the database after rebuilding from source for the new theme to be applied.

[joyfullservice]

The following works for me using the Testing database:

1. Open a form in design view
2. Change theme to Angles
3. Export all source - Angles theme appears in source files
4. Build from source
5. Close and reopen database for the applied theme to take effect. (Important)
6. The custom theme is displayed and exports to source.

That's the intended behavior. I did notice some interesting things when I toggled back and forth between different themes, and it didn't always seem to load these properly, especially when it started renaming the theme files.

[joyfullservice]

I did find something interesting though... While you have one theme set for the database, you can also have additional theme(s) applied to specific objects. In this scenario, you might have multiple themes included in your database file.

At present, all the themes are exported, but only the main database theme is imported when the database is built from source.

I am not seeing any changes in the present source files that map the Executive theme to frmMain, so there must be another mapping somewhere in a system table or other property that contains this link. 🕵️ Let's see who can find this missing clue... 😄

[A9G-Data-Droid]

This might be the case. Now that you mention it I think I have my theme applied at a form level.

[joyfullservice]

Sounds good. If it's helpful, the following links have some interesting info about Access system tables, including some information about deeply hidden tables that you can't normally see in a database.

http://www.mendipdatasystems.co.uk/purpose-of-system-tables-2/4594446647
https://www.access-programmers.co.uk/forums/threads/purpose-of-system-tables.300451/

[joyfullservice]

It turns out that the link to the theme applied to a specific form is right where you would logically expect it to be... In the form definition block. Not sure how I missed that before. 😄

The actual underlying problem for this issue was that the VerifyResourcesTable function was failing to return true if the system table exists in the database. This caused any additional themes to not be imported.

@A9G-Data-Droid - I just pushed an update to the dev branch. In my testing it seems to work correctly now, importing all of the themes from the source folder, and applying them to the correct forms. Let me know if this resolves the issue for you!

[joyfullservice]

I will go ahead and mark this as resolved, but feel free to reopen the discussion if you are still having issues with using custom themes. (Just be sure to restart the database after build for the theme to take effect.)

[A9G-Data-Droid]

This issue is not resolved for me using 3.4.5

I have to set the theme at the form level after rebuild and reopen. Exporting and building again I see the same behavior in a loop.

[joyfullservice]

I am having trouble reproducing this... In the testing database I have a main database theme, and a theme applied to a specific form. Both of these come through just fine after a rebuild. Important note: You need to close and reopen the database after the build to see the theme changes.

What happens when you build the testing database from source, close it, and reopen it again? Is the Executive theme applied to the main form, while the (database default) Angles theme is applied to other objects?

[A9G-Data-Droid]

If I build the test DB, close and reopen I immediately see two tests failed:

NOTE: I don't see any themes named Angles or Executive. Are those custom?

[joyfullservice]

Thanks! That is helpful. The Angles and Executive themes are part of Office 2010, and should be present in the themes source folder. Are there any errors in the log file relating to the themes? Would you be able to step through the theme import to see if you can identify the problem? I just don't have easy access to a computer with newer versions of Access to test it myself...

[A9G-Data-Droid]

This is from my build.log:

-------------------------------------
Importing themes...           
  Angles.thmx

-------------------------------------
ERROR: Unable to create MSysResources table.
-------------------------------------
Source: clsDbTheme.VerifyResourcesTable
  Executive.thmx

-------------------------------------
ERROR: Unable to create MSysResources table.
-------------------------------------

[A9G-Data-Droid]

When stepping through I can see that the VerifyResourcesTable contains a call to CreateForm() that is supposed to generate the MSysResources table. This seems unnecessary and the only reason this is happening is because the theme is the first thing imported. If we imported the themes later, after the DB has objects created in it, then all the system tables would have been generated organically.

[joyfullservice]

Would the forms come in correctly if the specified theme did not exist? Particularly forms that used specific named themes? You can try moving the theme line in GetAllContainers to the end, (such as right before the clsDbTableDataMacro line) and see if that resolves the issue.

It still would be nice to know why creating a form is not generating the needed system table, but that would require testing in a newer version of Access that I don't have easy access to.

[hecon5]

I built from latest dev today, built Testing from code, and checked the build. 39 tests passed.

Exported the built database, and noticed a few things, namely that the font changed or was removed.

21c21
<     DatasheetFontName ="Franklin Gothic Book"
---
>     DatasheetFontName ="Calibri"
23,25d22
<     AllowPivotTableView =0
<     AllowPivotChartView =0
<     AllowPivotChartView =0
159d155
<                     FontName ="Franklin Gothic Book"
189d184
<                     FontName ="Franklin Gothic Book"
207d201
<                     FontName ="Franklin Gothic Book"
225d218
<                     FontName ="Franklin Gothic Book"
243d235
<                     FontName ="Franklin Gothic Book"
261d252
<                     FontName ="Franklin Gothic Book"
279d269
<                     FontName ="Franklin Gothic Book"
297d286
<                     FontName ="Franklin Gothic Book"
315d303
<                     FontName ="Franklin Gothic Book"
334d321
<                     FontName ="Franklin Gothic Book"
355d341
<                     FontName ="Franklin Gothic Book"
376d361
<                     FontName ="Franklin Gothic Book"
397d381
<                     FontName ="Franklin Gothic Book"
415d398
<                     FontName ="Franklin Gothic Book"
433d415
<                     FontName ="Franklin Gothic Book"
453d434
<                     FontName ="Franklin Gothic Book"
471d451
<                     FontName ="Franklin Gothic Book"
490d469
<                     FontName ="Franklin Gothic Book"
510d488
<                     FontName ="Franklin Gothic Book"
530d507
<                     FontName ="Franklin Gothic Book"
549d525
<                     FontName ="Franklin Gothic Book"
568d543
<                     FontName ="Franklin Gothic Book"
587d561
<                     FontName ="Franklin Gothic Book"
607d580
<                     FontName ="Franklin Gothic Book"
625d597
<                     FontName ="Franklin Gothic Book"
635,637c607,609
<                     BorderColor =11710639
<                     HoverColor =13355721
<                     PressedColor =6249563
---
>                     BorderColor =14461583
>                     HoverColor =15189940
>                     PressedColor =9917743
654d625
<                     FontName ="Franklin Gothic Book"
663,665c634,636
<                     BorderColor =11710639
<                     HoverColor =13355721
<                     PressedColor =6249563
---
>                     BorderColor =14461583
>                     HoverColor =15189940
>                     PressedColor =9917743
682d652
<                     FontName ="Franklin Gothic Book"
693,695c663,665
<                     BorderColor =11710639
<                     HoverColor =13355721
<                     PressedColor =6249563
---
>                     BorderColor =14461583
>                     HoverColor =15189940
>                     PressedColor =9917743
712d681
<                     FontName ="Franklin Gothic Book"
723,725c692,694
<                     BorderColor =11710639
<                     HoverColor =13355721
<                     PressedColor =6249563
---
>                     BorderColor =14461583
>                     HoverColor =15189940
>                     PressedColor =9917743
742d710
<                     FontName ="Franklin Gothic Book"
749,752c717,720
<                     BackColor =11710639
<                     BorderColor =11710639
<                     HoverColor =13355721
<                     PressedColor =6249563
---
>                     BackColor =14461583
>                     BorderColor =14461583
>                     HoverColor =15189940
>                     PressedColor =9917743
769d736
<                     FontName ="Franklin Gothic Book"
780,782c747,749
<                     BorderColor =11710639
<                     HoverColor =13355721
<                     PressedColor =6249563
---
>                     BorderColor =14461583
>                     HoverColor =15189940
>                     PressedColor =9917743
897d863
<                     FontName ="Franklin Gothic Book"

[A9G-Data-Droid]

So I moved the theme import down a bit, but not passed the forms. This fixed the theme import issue but then I ran in to #236. So I saved all the modules and reopened, only to find that "Module Description" test failed. I'm also seeing the font issue raised by @hecon5

If I test it manually to see what is in there I get:

? CurrentDb.Containers("Modules").Documents("basUtility").Properties("Description")

[joyfullservice]

@A9G-Data-Droid - Thanks for the update!

That is an interesting observation regarding the theme import... I think we are probably okay moving this as long as it comes before any forms or reports, since those objects use themes.

I did a little testing with the font issue, and it looks like some of the theme-related properties are not fully initialized until the form is opened in either design or form view. You can test this to see the difference by building the Testing database from source, closing it and opening it again to make sure the themes are loaded, then open and close both of the forms. At that point you should get a pretty clean export. This may possibly mean that we need to open imported forms in design view for them to fully load in the context of custom themes, etc... Of course this carries a performance penalty with it.

One idea to minimize the performance penalty while still retaining the complete export would be to store a flag in the index file that indicates that the form (/report?) was opened since the last export. If the modified date is newer than the date saved at the time of import, we would know that it had been opened at least in design view, and should be fine. If the date still matches the import date, and fast save is on, it wouldn't be exported unless it was changed/saved, so it would be skipped during a routine export. (No performance penalty.) When a form is exported, the index would be checked, and if it hasn't been opened, it would be opened (hidden) in design view, then immediately closed. (We would have to test to see whether a save is necessary.) Then it would be exported right after that.

This approach would slightly slow down the export for (only) the first time the object is exported after import. It seems like this might be a workable option to be able to still maintain consistent output without adding too much of a performance penalty on the build or export. I suppose we could even provide the option to do this for all forms immediately after build, or on demand during export as described above, or not at all, for those that don't really care about the change "noise" and just want VCS to be as fast as possible.

[joyfullservice]

Regarding the module description issue, that is likely because the modules had only been created in VBE, but not yet been saved as database objects so Access could not attach the custom description property since that lives on the Access side. When #236 is resolved, that should take care of that particular issue.

[A9G-Data-Droid]

I would opt add time to the build process. It's used far less frequently and historically, compiling takes a long time. It's okay to take your time and do it right.

[hecon5]

I'll second @A9G-Data-Droid, I'm already at 200+ seconds to build (thanks to table linking), so a second or two is going to make no noticeable difference to me.

[joyfullservice]

I just pushed a couple updates to initialize the forms after import, and fix an issue with the import sequence. This is now giving me consistent color/font/theme output between builds.

[A9G-Data-Droid]

So I built the latest dev. Installed. Built the latest test.

I got build errors:

ERROR: Setting Property 'HelpContextId' to value '123456'
-------------------------------------
Error 440: Automation error Source: clsDbVbeProject.SafeSetProperty

ERROR: Build error in: Testing.accdb.src\documents.json
Error 3265: Item not found in this collection. Source: modImportExport.Build

ERROR: Build error in: hidden-attributes.json
Error 2950: Reserved Error Source: modImportExport.Build

and a failed test:

[joyfullservice]

Yes, this is related to the import of the code modules. (#230) I think we are going to need to go with the hybrid approach of using LoadFromText and overlaying the VBE if needed to load hidden VBA code attributes (not to be confused with the Microsoft Access hidden attribute that hides the module from the object list.)

I have an idea on how to efficiently do this, but I may or may not have time to flesh it out today. But once this is done, we should be pretty close to wrapping up for the 3.4.x release.

[A9G-Data-Droid]

NOTE: You can use RubberDuck to ensure that hidden attributes are documented in visible code. It will tell you in the code inspection window when the actual attribute is missing, based on the documented comment.

DETAILS HERE: https://rubberduckvba.com/Annotations

[joyfullservice]

I believe this has been resolved as of the latest dev build 3.4.10. I am able to perform round trip builds with the testing database with no issues. Let me know how it works on your end!

[hecon5]

It appears to work on the testing database; though I do see this in the diff:

-    AllowPivotTableView =0
-    AllowPivotChartView =0
-    AllowPivotChartView =0

I'm running on my complex database now.

[joyfullservice]

I'm running on my complex database now.

Thanks! It looks like this project was featured on https://nolongerset.com/instant-version-control/ on Friday, so I am thinking it would be good to roll out the 3.4.x update sooner rather than later, so any new users can take advantage of the latest features and file formats.

[joyfullservice]

It appears to work on the testing database; though I do see this in the diff:

-    AllowPivotTableView =0
-    AllowPivotChartView =0
-    AllowPivotChartView =0

This would be expected, since Pivot Tables were removed in Access 2013.

[hecon5]

Color export/import functioned as expected on my complex database IRT themes; the correct theme file is exported, and I don't have duplicates!

[joyfullservice]

Awesome! I will go ahead and close this out as resolved, unless we encounter anything further with themes.

[A9G-Data-Droid]

I'm running on my complex database now.

Thanks! It looks like this project was featured on https://nolongerset.com/instant-version-control/ on Friday, so I am thinking it would be good to roll out the 3.4.x update sooner rather than later, so any new users can take advantage of the latest features and file formats.

@joyfullservice Wow! You're famous!

[joyfullservice]

@joyfullservice Wow! You're famous!

Well, I don't know about that, but thanks!! 😉 I am just glad to know that the project has been helpful for others as well. It has certainly revolutionized database development for me, and hopefully can continue to help others to continue developing Access applications with greater efficiency and collaboration for years to come. Thank you for your contributions as well! I am grateful for all you did in sorting out the Unicode issues and other things along the way.