Error 7960 after build master-branch with "Build from Source"

[Tanarri]

Hi,

I want to build the Version V3.2.2 on my own from the githib source.
Build goes right, but when I start the builded access-db "Version Control.accda" there is a error 7960

The problem is that the imported class is imported es module. See

Infos:
The installed and used Version is V3.2.2. With this Version I use the function "Build from Source" on the downloaded source from github.

Enclosed the log.txt of "Build from Source"
Import.log

Greetings
Tanarri

[hecon5]

Dumb question: what happens when you build dev branch?

There may be a locale issue with IDbComponent, can you manually reference in Windows Script Host Object Model?

[joyfullservice]

If I compare the exported text files for standard modules and class modules, it seems that the attribute lines at the top is what tells Microsoft Access that it is a class module.

If you reinstall the latest version of the master branch from the releases page, then try building the dev branch from source, do you encounter the same issue?

Another question for you... Do you use a particular software for managing the files on the GitHub project? I personally use GitHub Desktop, which makes it really easy to switch branches, update from master, etc... SourceTree is another great option if that is more familiar.

You can also try a test export and import of a class object directly from the VBA Immediate window using the native commands, to see if the object is imported properly. (By default it will probably export to your Documents folder.

application.saveastext acModule, "clsAdpFunction","clsAdpFunction.bas"
application.loadfromtext acModule, "clsAdpFunction","clsAdpFunction.bas"

Let us know what you find out! 😄

[Tanarri]

Hi @hecon5,

yes, the the builded access-DB there is a reference to the "Windows Script Host Object Model"
enclosed a video of how I builded it.

Greetings
TanarRi

[Tanarri]

Hi @joyfullservice ,

I have installed the Version V3.2.2 from releases and started it. I don't installed it, as the programm requested, then opened the VBA Editor.
After that I saved and loaded a class as you wrote:

application.saveastext acModule, "clsAdpFunction","clsAdpFunction.bas"
application.loadfromtext acModule, "clsAdpFunction","clsAdpFunction.bas"

Info: After the export I deleted the class "clsAdpFunction"

All right. The class "clsAdpFunction" is imported as class and not modul.
If you with I can also make a video of it.

Greetings
TanarRi

[joyfullservice]

@Tanarri - Attached is a copy of the add-in built from the latest dev branch. If you open this file, allow it to install, then are you able to build the dev branch from source?

Version Control.zip

If that doesn't work, you can place a copy of the attached Version Control.accda in the \msaccess-vcs-integration\ folder of the GitHub project, open the file, and build it from there.

It is possible that we might be encountering an issue with the default system codepage or character set to where Access might be encountering a BOM or some other issue with the text file that causes it to not read correctly. If this is the case, it could be something that we could adjust in LoadComponentFromText. Perhaps you could compare the exported file with what you are finding in the GitHub project... Is there a difference in the file format? The exported class module files on my system are UTF-8/windows-1252, and I get an identical file whether I export through VCS or Application.SaveAsText.

You might also check the New Database Sort Order in Access options to see if there is anything special happening there.

[Tanarri]

Hi @joyfullservice ,

thanks for you support!
I will do my best to answer your questions.

I have downloaded your Zip and installed the V3.2.3 and also downladed the actual DEV-branch as ZIP (no I don't use git at the moment on this PC) and extracted it.
-> I was able to build the dev-branch from source, but on opening the builded accdb - same error --> the classes were imported as modules

Then I copied your accdb from your ZIP into \msaccess-vcs-integration\ and tried to build the dev-branch again.
-> I was able to build the dev-branch from source, but on opening the builded accdb - same error --> the classes were imported as modules

Sorry, this doesn't help.

Next steps to get more infos.
Opening the file "clsAdpFunction.bas" from the githib ZIP file in Notepad++
-> UTF8 (Unix LF)

Export the class "clsAdpFunction.bas" from the accdb from your ZIP, and open it in Notepad++
application.saveastext acModule, "clsAdpFunction","clsAdpFunction.bas"
-> UTF8 (Windows CR LF)

Export the class "clsAdpFunction.bas" from the accdb from your ZIP with "VCS - Export all source", and open it in Notepad++
-> UTF8 (Windows CR LF)

Next try on my own Idea:
Opening the file "clsAdpFunction.bas" from the githib ZIP file in Notepad++, which is "UTF8 (Unix LF)"
--> Convert "UTF8 (Unix LF)" to "UTF8 (Windows CR LF)"
and build it again..
SUCCESS with the file! It is now imported as a class and no more as a module.

the "new database sort order" is an other than yours.
Mine is "general - old version" (hope I translated it correct)

Now I will try following testings and report you
a) Convert all modules *.bas files to "Windows CR LF" and try to build th dev-branch
b) Changing the "new database sort order" to "general"

Greetings
Tanarri

[joyfullservice]

Good job finding the difference in the line endings! That gives a very reason why this was happening. It looks like the problem came from the way you downloaded the files from GitHub, but the good news is that it should be easy to correct with a line in the .gitattributes file. I will update that shortly. 👍

[Tanarri]

Hi @joyfullservice ,

the newest test result:
I had converted all files cls*.* and I*.* (VBA classes) to "Windows (CR LF)" and then I was able to build the dev-branch.

Cool that this would be easy to fix with .gitattributes

Do you think this could also be handled in VCS, when it import the wrong line endings? e.g. Rewrite the file temponary before import hte class/module?

Greetings
Tanarri

[joyfullservice]

Do you think this could also be handled in VCS, when it import the wrong line endings? e.g. Rewrite the file temponary before import hte class/module?

That's a good thought, but I think this would be a very unusual case, especially after making the change to .gitattributes. Rewriting the files would have a performance impact, so I am leaning towards just expecting the files to be in their original condition. We can certainly revisit this issue if it comes up again in the future.

[Tanarri]

Fix of @joyfullservice tested and it works
great!

[linux4life798]

Any insight into whether we need to ensure *.cls files are CRLF, too?

[joyfullservice]

@linux4life798 - I am not aware of any issues reported on this, but it's not a bad idea to go ahead and cover the rest of the source file extensions as well, just in case. I just pushed a commit for this.