Modules not created with their correct names when using "Build From Source"

[ollypsilon]

Hi!
I want to use/test the dev branch version.
I've create a fork and a local repos with a custom brach name as described in Editing and Contributing.
When I use the master version 3.4.23 to create the dev version like described here
"Use the add-in to Build From Source, selecting the cloned Version Control.accda.src folder." I have lots of modules not created with their correct names, compilation fails due to this.

All failed modules have these strange characters "" at the beginning of their exported name, e.g. Attribute VB_Name = "modAddInMenu".
Is it my mistake and I did something wrong, is it a bug in module export to .bas or what causes this?

And I found this in Build.log:
Importing modules...
modAddInMenu.bas
ERROR: Build error in: [...]\git repositories\msaccess-vcs-integration\Version Control.accda.src\modules\modAddInMenu.bas
Error 2489: Das modAddInMenu-Objekt ist nicht geöffnet. Source: modImportExport.Build

Is it related?

Best

Oliver

[ollypsilon]

I think it might be due to .bas files on my system are encoded as UTF-8 and not ANSI and Access seems to need ANSI encoded files during import. Because the same issue happens when I manually import the .bas files to a project.

[joyfullservice]

@ollypsilon - The dev version includes a number of enhancements and improvements over the current master branch, so I decided not to try to take the time to build all the forward-compatibility into the master branch. The dev branch builds easily from any recent dev version of the add-in, but obviously you need a compiled version to start with. 😄

To answer your question on the modules, after much discussion and review, the most robust source code export seemed to be that of using a UTF-8 BOM so that software applications would universally recognize the encoding of the VBA source content.

I think maybe what might be the easiest solution here is for me to publish a "pre-release" version from the dev branch. Then anyone wanting to test out the development version can just download it from the releases page. This pre-release version could be used to build the dev branch, or simply to test out some of the new features.

I just published a binary release of the dev version 4.0.5-beta. After installing this version, you can test out the features in your projects. You can also use this to build the dev branch. Let me know how this works for you!

[joyfullservice]

Thanks for the update! Your feedback gave me an idea. Since this is really only an issue when importing VBA code modules, I have added an optional parameter in the codepage detection to fall back to a non-UTF-8 codepage when a user has the Beta Unicode option checked in Windows 10. (This fallback is only used for importing code modules, since the VBE does not have inherent UTF-8 support.) I haven't tested this because I don't use the beta option on my system, but I think this should allow the add-in to work correctly even if that option is checked.

We have had at least one other user that actually needed this beta option for a database that used Unicode characters on forms, so I think this may be a help for cases like that as well. For now I am hard-coding the Windows-1252 fallback, but this could be extended in the future to support other code pages through a user-selected option.

If you build the dev branch from source, restart Access, then double-click the newly built add-in file to install it, you can test it out on your system to see if you can successfully build projects even with the beta option checked.

[ollypsilon]

So, I've built the add-in from your updated files and installed it. No issue with it.
But for my database I can't create it from source. When exporting with UTF-8 beta option checked .bas files are unreadable and cause errors during build. With UTF-8 beta option disabled export is fine, .bas file are human readable but import has issues.
Some tables are empty and I get a bunch off error messages in Build.log and in Importerrors table.
Feel free to drop my a PN if you need details or if you want me to share details here.

[joyfullservice]

@ollypsilon - Are you using actual UTF-8 characters in your VBA source code? I don't think the VBE technically supports Unicode, but I don't know exactly how it works with the UTF-8 beta option selected... Perhaps you could try exporting a module manually through VBE, then open the file in Notepad++ and check the encoding. It may be that I need to account for a different encoding there.

If you would like to create a private repository on GitHub, and add me to it, I could take a quick look at your database and source files, and see if I can identify what is happening there. On most systems the add-in seems to work right out of the box, but it is nice to solve some of those edge cases for the benefit of others that might encounter similar issues in the future.

[ollypsilon]

@joyfullservice Well, maybe a misunderstanding: it's not about VBA code exports, it's all export like e.g. table definition's .bas file which is unreadable when UTF-8 beta option is set. Without the option the .bas file is fine. On build from source the tables are generated but loading data for the ones which are exported with data fails, maybe due to UTF-8 chars in data. I will check this.
Unfortunately I'm not allowed to share the whole project due to company policy. I'm going to create a kind of debug database with just some content, allowing to reproduce the errors we got.

[joyfullservice]

Thanks, @ollypsilon! I was able to look at the sample database, and identified four issues. I will probably break these out into individual issues so they can be worked through individually.

• Content encoding issue when exporting form objects when using the UTF-8 Beta option in system language settings.
• Error parsing dates coming from different locales. (Perhaps determine a standard format that works on all systems.)
• Issue with GetUncPath function, resolved with 3b9809c.
• Problem importing table data when calculated fields are involved. (I have tested a solution to resolve this.) Import XML Table Data into a Table Containing Calculated Fields #379
• Shared image name conflict during import (rare case) #380

The good news is that aside from these issues, I was able to successfully build your sample database. 😄 I am pretty sure that together we can come up with a solution that will work for the UTF-8 Beta option (which I would like to support, if we can). The other issues all seem to be things we can resolve without too much difficulty.