Code Catalog for Access / VBA - Making Code Sharing Easy

[Josef P.]

Inspired by some recent forum posts and the ideas mentioned at Access DevCon 2023, I’d like to open a dedicated thread to discuss the concept of a shared catalog of reusable code modules and add-ins for Microsoft Access / VBA.

Let’s gather here what already exists (tools, code collections, relevant repositories, add-ins, etc.) and discuss possible approaches for offering such a catalog to the community.
Whether it’s a simple GitHub repo, an Access Add-In, or a combination of both – all ideas are welcome. Let’s evaluate what’s feasible, what’s helpful, and what’s maintainable.

A few more quotes from the other thread:

It would be nice if we could have all those classes and modules made by others in one place where we can simply select and bring into our development environment. Sort of like npm for NodeJS or nugget within .Net, you would not even need to classify them, you would just search for them and with simple gesture you'd be ready to use them. Such a thing would require an add-in, perhaps, but it would be a useful add-in, for sure.

[OT: "npm" for Access]

The same would also be useful for add-ins etc.
Ideas have already been introduced in prominent place (Access DevCon 2023):

If there were a "catalog" of these code modules, an add-in could be developed with a manageable amount of effort. (I already use an add-in for importing code modules including their dependencies, which could be expanded or parts of it could be used).
Since I also consider this to be useful, I would be happy to discuss ideas/conceptions about such an add-in + catalog in more detail.

Yes, that’s exactly what I was referring to. Being able to find and mindlessly integrate stuff without a paywall and with an active community of people improving it and keeping it alive would definitely bring some life to this.

@Josef P.
I would share some time for that thread, if you're willing to maintain it. Hopefully others do too.

Using Access’s File Insert with a GitHub Code Repository

Microsoft Access’s Visual Basic Editor (VBE) includes a handy **Insert > File** feature, allowing you to insert the contents of a text file (e.g., `.txt` or `.bas`) directly into a VBA module during editing.

This is perfect for reusing code snippets or templates stored locally. To enhance this, you can link the local folder to a **GitHub repository**, creating a centralized, online repository of code samples accessible to your team or community.

By cloning the repository to a local folder (via `git clone`) and keeping it synced with `git pull`, you can browse and insert the latest code samples using Access’s built-in feature.

For inspiration, the **msaccess-vcs-addin** project by joyfullservice on GitHub (https://github.com/joyfullservice/msaccess-vcs-addin) uses a similar concept for version control, exporting Access objects as text files and recommending UTF-8 encoding for compatibility with Git.

This approach combines Access’s simplicity with GitHub’s collaborative power, streamlining code reuse.

 

[Josef P.]

Using Access’s File Insert with a GitHub Code Repository

I already do that.

But these are just my code modules. My GitHub repository for VBA code: https://github.com/AccessCodeLib/AccessCodeLib

A catalog of several repositories with such code modules would be interesting.

 

[Josef P.]

Found on GitHub:

GitHub - sancarn/awesome-vba: A curated list of awesome VBA/VB6 frameworks, libraries, software and resources

A curated list of awesome VBA/VB6 frameworks, libraries, software and resources - sancarn/awesome-vba

github.com

 

[isladogs]

@Josef P.
Thanks for the GitHub link which I've not seen before. No idea who any of the contributors are.
Whilst much of the material appears to be to web pages I'm already aware of, its useful as a curated list

 

[GPGeorge]

The GitHub awesome-vba site is heavy on Excel, but I'll bet we can improve the Access content a lot by adding additional links. I see Daniel Pineault's site and Colin's site but not many others.

At first sight, and without digging into all of the links, it does seem that it could possibly benefit from resources on 64-bit compatibility. Has anyone looked into that?

 

[GPGeorge]

The GitHub awesome-vba site is heavy on Excel, but I'll bet we can improve the Access content a lot by adding additional links. I see Daniel Pineault's site and Colin's site but not many others.

At first sight, and without digging into all of the links, it does seem that it could possibly benefit from resources on 64-bit compatibility. Has anyone looked into that?

On closer examination, I see other Access sites.

The question in my mind is whether this format is what is really in the spirit of this idea. It seems to be composed of links to other sites than would, in turn, have to be searched.

 

[Josef P.]

I see a 'catalog' on GitHub more machine-readable. Perhaps one JSON file or similar for each repository.
It might even be possible to create HTML pages directly via a workflow.

The main effort of a “catalog” will be in maintenance and updating.
Therefore, GitHub could be a useful platform if people can be found to create pull requests, etc.

The technical implementation of bringing code into the application doesn't cause me much trouble. You "only" need to know the exported state (SaveAsText or vbComponent export).

While the technical implementation seems manageable, I do have some doubts about community engagement. But I am happy to be proven wrong.

 

[Josef P.]

Vision: .. and later create an add-in with AI support to find the required code modules

 

[GPGeorge]

I see a 'catalog' on GitHub more machine-readable. Perhaps one JSON file or similar for each repository.
It might even be possible to create HTML pages directly via a workflow.

The main effort of a “catalog” will be in maintenance and updating.
Therefore, GitHub could be a useful platform if people can be found to create pull requests, etc.

The technical implementation of bringing code into the application doesn't cause me much trouble. You "only" need to know the exported state (SaveAsText or vbComponent export).

While the technical implementation seems manageable, I do have some doubts about community engagement. But I am happy to be proven wrong.

"Community Engagement". All too likely evolving to mean something more like, "Let me know when it's ready for me to download some code."

I do share enthusiasm for the idea. I'm not optimistic about the process. It'll take a handful of intrepid entrepreneurs who are not easily discouraged.

 

[isladogs]

As previously mentioned, I think this is of use as a curated list but I don't see it as being any different to / better than web pages such as Useful Links on my website.

 

[GPGeorge]

As previously mentioned, I think this is of use as a curated list but I don't see it as being any different to / better than web pages such as Useful Links on my website.

The difference would be, assuming I'm interpreting the intent of a GitHub repository correctly, is that there would not be links to other websites. My assumption would be that people who wanted to share the code would push it into that GitHub repository.

 

[isladogs]

Yes I understand the difference. My previous comments were referring to the awesome-VBA page on GitHub

I also like the idea that’s being suggested in #7/#8 but also share doubts about its viability.

 

[Josef P.]

My assumption would be that people who wanted to share the code would push it into that GitHub repository.

A basic requirement for me would be that the code is provided as a text file and not within an accdb.
Whether it is then available in just one or in multiple repositories doesn’t really matter to me.

I am currently thinking more in the direction of a catalog that enables automated import from several repositories into the Access application.

I had the idea of a shared repository many years ago when I created access-codelib.net (in German).
Active participation in contributing code: you could count it on one hand.
If you put everything into one repository, I think you also have to think about what code quality you want.

Multiple repositories can also have an advantage: the programming style probably remains more uniform within the respective repository and you could use special repositories such as VBA-JSON or VBA-MicrosoftGraph in the same way.
Another advantage of distributed repositories: each provider has sovereignty over his own repository and does not have to “bother” with changes that others incorporate into the code but which do not meet his expectations.

 

[Edgar_]

Here's how I envision it. It has three main parts:

1. The centralized registry of packages.
2. The developer or developers who create and publish the package.
3. The developer who will be using the package.

Scenario:
On a typical day, a developer is working on a form and realizes that a particular combo box should filter its options as the user types. The developer might know how to build this from scratch, or maybe not, but luckily there's a tool available within their environment that helps them integrate existing solutions.

What you as a user of packages will do:
First, the developer opens this tool, which presents a list of popular packages that can be imported. Somewhere in the tool, there's a search bar placed conveniently. The developer types something like 'combo box' or 'filter combo' into the search.

Next, the tool displays a list of packages that match the search criteria. Some example results might be:

• 'Combo Box Cascader' by MikeTools
• 'Filter Combo Boxes, List Boxes, Any List and More' by AlfredTheVBAMaster
• 'FAYT Filter Combos' by @MajP
• Other related packages

The developer can click on any of these options to view an overview of what the package does, but more importantly, how to use it. This helps the developer quickly decide if the package meets their needs before choosing to integrate it. The overview also includes useful details like the number of downloads, issue reports, developer reputation, and other indicators that help with the decision-making process.

Once the developer finds a suitable package, they can click to download it. At this point, the tool provides options based on how the developer wants to integrate it. For example, they might choose to:

• Import just the class module.
• Include a sample form.
• Add a sample database.
• Insert a few lines of code into a selected module to initialize the tool.

This makes it easy for the developer to customize the integration process and get up and running quickly without manually copying code or hunting through examples.

What a package developer will do:
Now, on the other side, the developer who makes the package should make sure to provide:

• A clear description of what the package does.
• A readme or usage guide with examples.
• Version numbers for each release.
• Information about dependencies, if any.
• A changelog explaining what's new in each version.
• Optional sample files like forms or sample databases.
• Metadata like author name, license type, and optionally a trust badge if the platform supports it.
• This makes it easier for others to understand what they're installing and how to use it right away.

We could use GitHub for some of these things.

The centralized registry:
Github could be used to store and serve all packages, their metadata, and any associated sample files, but we need an service to orchestrate the whole process. This other service should be able to:

• Provide an API or service that the tool uses to search, fetch package info, and download packages.
• Track download counts, version history, issue reports, and developer profiles. Same as above.
• Enforce publishing rules, like no duplicate package names, versioning, file size limits, etc.
• Support developer verification and trust scoring to help users identify reliable packages.
• Allow package removal or deprecation, that would be tricky, though.

This part is obviously the hardest, because we're not really sure if it's even going to be used and it requires a ton of development effort. However, we can create a light way version that does the minimal and see how well it is adopted, sort of like an MVP (Minimum Viable Product).

 

[Edgar_]

There are a lot of differences between what I'm talking about here and what's currently available today.

1. What we have right now forces us to go hunting for what we really need. You have to dig through forums, blog posts, random GitHub gists, or old articles just to find a simple utility or code snippet.
   With this tool, you could have everything organized and available right where you need it, inside your environment, without breaking your workflow.
2. When you do manage to find something, the next problem is figuring out how to use it. You have to hope there’s a decent explanation, check if other people are even using it, and see if it's still being maintained.
   With this tool, all of that would be easy to know up front, you’d get a clear description, usage instructions, sample code, download numbers, feedback from other users, and an idea of how reliable or trusted the developer is.
3. A lot of times, good tools or code get buried inside a long forum thread or hidden deep in an old article. Worse, some great solutions just sit there unnoticed because no one ever stumbles across them. And sometimes people grab code, use it in their projects, and never give credit or feedback, so the original developer has no idea if their work is helping anyone.
   With this tool, both problems get solved, as users, we’d immediately know what's available and whether it works. And as developers, we’d finally get visibility and feedback through metrics like download counts, usage stats, issue reports, and maybe even ratings or comments.

On top of that:

• Package makers would get a proper, centralized way to share their work, with a profile, verified status, and real-time metrics.
• Users wouldn't have to waste time downloading outdated or broken code, since every package could show last updated dates, version histories, and issue counts.
• The tool could recommend related packages, or newer alternatives to the one you're looking at.
• It could help prevent duplicate or redundant tools, since developers would see what already exists and either improve it or build something genuinely new.

And this is just scratching the surface. There's a lot more this kind of system could improve. Access is basically a joke right now, let's be honest here. People don't even find Access as a living thing, it doesn't even exist for a ton of developers out there. With a tool like this, that could change and force Microsoft to finally give some love to the app like they give love to Excel, maybe. A lot of ideals here, I know.

 

[Edgar_]

I forgot a key aspect to this, we HAVE TO integrate some form of AI in many of the steps. Luckily for us, there's plenty of LLM models out there to help with that. We could, ideally, let the LLM have some context of our environment and let it control it. That would really be the GOAT.

 

[Josef P.]

This for Access:

 

[Edgar_]

Now, since there are a lot of repos hanging out there in the wild, we could integrate them if their license allows it and then let the user claim their authority over it.

 

[Edgar_]

This for Access:

Or this

 

[Edgar_]

As for how to make it viable, one good starting point would be to reach out to the owners and admins of the different forums and communities where developers already hang out. We could ask for their help to promote the tool and make it visible to as many developers as possible. Even just having a pinned post, a banner, or a mention in a newsletter would go a long way in getting eyes on it. Or just straight up word of mouth if forums don't want to help.

If the tool picks up enough traction and starts getting widely used, it might eventually find its way into the datasets of large language models. And once that happens, you could have LLMs suggesting something like, "Hey, download this tool and just search for this package, here's how you use it". It would turn into a self-sustaining loop where people find the tool, use it, and the AI suggestions help surface it even more. It should not be that difficult, take the VBA-JSON library as example, the LLMs know it.

It's one of those things where if the community adopts it early, it has a real shot at sticking around and becoming part of the normal workflow.