OpenArgs (my) class way (1 Viewer)

[Edgar_]

What I call "the framework way".

And that's a great thing. All other development kits are using frameworks for everything, saving thousands of hours, but nothing is really out there yet for every day Access development, save for a few classes and modules here and there to handle very specific scenarios.

 

[jwcolby54]

By the way, debugging Excel, Word, PowerPoint, Access, even AutoCAD is all the same. You just work with different objects.

This is true. I have done work in Excel, Word, Access and Outlook. The biggest issue there is that the environment is completely different from Access. We really do have the "best" environment for easily and quickly writing code. And also re where the code is stored. In a worksheet? Really?

I used to use the Excel widget that recorded keystrokes and such (a really powerful and useful tool), but then pull that code back into Access to store. Wrap it and call it and get stuff done.

I recently used events in outlook, sunk in Access, to capture Outlook email, check the from / to and subjects to catch orders coming in to a small business where they used emails in that manner. It worked quite well, I could grab an email and pull the stuff out of the email message to create orders in the order table. Events raised in Outlook, sunk in a class in Access. In theory one could do the same in any of the office apps.

 

[jwcolby54]

And that's a great thing. All other development kits are using frameworks for everything, saving thousands of hours, but nothing is really out there yet for every day Access development, save for a few classes and modules here and there to handle very specific scenarios.

I was around before windows, and back then DOS was the "ultimate framework". In the end it is really about the bios handling the very low level stuff, disks, serial ports, interrupts, memory managemt (at the very basic level) and then building up on that to give us devs hard drives, displays, keyboards, mice, memory etc. I remember when we had to understand that stuff.

Now I just open Access and Windows handles all the underneath stuff for Access. And now I just open Access and Access handles all the minute details of tables, fields, indexes, forms, controls and so forth. Access is a database framework on top of the Windows framework.

And so why not build a framework on top of Access to handle a bunch of stuff when an App opens, When a form opens. Get the Sysvars which run the framework loaded out of various sysvars tables and cached into memory in classes. I had a sysvar table for the framework itself, for the application and for the client info. The framework sysvars had default values in my Framework library, which were pulled into the FE the very first time that I initialized the framework for a new FE. I could then override the framework sysvars in the fe if this specific fe needed to do something different from the default.

Get logs set up and working. An error log to log errors into tables if the framework sysvars said it was going to go into a table, or a file if the framework sysvars said it was going to log to file.

Then the form side of the house. clsFrm to manage forms as they loaded. Get the various behaviors ready for the form as it loaded.

A framework for me, written by me, to make my Access development easier. It took a couple of years, as I worked on client apps, but it got done and it made my life as a dev in Access much easier.

 

[Edgar_]

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.

 

[Josef P.]

[OT: "npm" for Access]

... have all those classes and modules made by others in one place where we can simply select and bring into our development environment ...

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.
However, I suggest an extra thread for this so that John's thread is not totally hijacked.

 

[jwcolby54]

[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.
However, I suggest an extra thread for this so that John's thread is not totally hijacked.

LOL, too late!

 

[Pat Hartman]

And that's a great thing. All other development kits are using frameworks for everything, saving thousands of hours, but nothing is really out there yet for every day Access development, save for a few classes and modules here and there to handle very specific scenarios.

Not true. OpenGate Software has some pretty interesting tools. So does FMSInc

 

[Edgar_]

I suggest an extra thread for this so that John's thread is not totally hijacked.

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.

 

[Uncle Gizmo]

If there were a "catalog" of these code modules,

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.

New Thread: https://www.access-programmers.co.u...r-access-vba-making-code-sharing-easy.334177/