OOP in Access Applications

Also, I had no idea data macros were a thing.
Macros are a thing ...

... and you did right to skip straight to VBA! :LOL: (Don't bother with Access macros).

However, Data-Macros are another thing. Pay some attention to these. They are a [poor] attempt to be equivalent to triggers on tables in more serious RDBMS's.
 
A lot of people who are comfortable with code think of Access as a second-class (or worse) environment. But as with all tools, it depends on what your task is. Access is actually a superior tool for a specific class of applications. It does most of the grunt work for you and is even flexible enough for you to use it to create classes to do magical things. But Access is not even close to being a general purpose tool the way VB and C and other languages are. Access creates data-centric applications with the least pain of any tool I've ever used or dabbled with. Some of my apps have been large with lots of functionality others have multi-million row tables and others have hundreds of concurrent users. One has all three. So, Access doesn't have the kind of limits it is panned for. Those limits are actually Jet and ACE, not Access the RAD tool.

My problem is that as a consultant, sometimes I get called on to have to fix applications created by the dregs of humanity and so I can tell you many of the worst practices out there and I can tell if the developer was a user learning as he went or an experienced developer who was for whatever reason forced to use Access, a tool he distained. Give me an app created by a user any day of the week. People who think they understand OOP are the worst offenders of all. Everything is a class whether it needed to be or not. And the old school concepts of coupling and cohesion are violated at every opportunity. Changing one class invariably breaks something else due to the tight coupling and low cohesion of the code.

So, you can never learn how classes work until you create one so I would never want to discourage you from learning how to create classes. Just don't think they are the first option you should be looking at. Access is a RAD tool and if you are going to use Access, you should use its RAD features which help you to avoid code;)
 
Macros are a thing ...

... and you did right to skip straight to VBA! :LOL: (Don't bother with Access macros).

Agree but with two exceptions: Autoexec and Autokeys, both of which have functionality that isn't directly replicable from VBA
 
Last edited:
Autoexec and Autokeys both of which have functionality that isn't directly replicable from VBA
Very true, luckily I did learn those but nothing else. Well, I learned the absolute minimum to get them running VBA so I could ditch whatever other scratch-like language they were using 😅
 
Access is a RAD tool and if you are going to use Access, you should use its RAD features which help you to avoid code;)
I think I see what you're saying. You can't exactly compare Access to other general purpose languages and environments. Access is more focused on a certain kind of application and comes with a lot of prebuilt components to help you quickly assemble that kind of application. It would be a shame to lose time making your own code all of the time when you could be taking advantage of these components and methods they already give you, because that's the strength of Access in the first place. Otherwise, you're just trying to use it like you'd use other tools that offer more full flexibility but make you write all those components yourself or grab some libraries from others, and you're bound to keep clashing against what Access is actually trying to be.

It's RAD, which is pretty rad as far as I'm concerned XD
 
Keep a list of VBA functions handy as you start to use Access as a RAD tool. I found it very helpful and I still use it to find functions I don't use frequently.

And here's a link to a tool I built to teach people how the event model works. Being an experienced programmer before I came to Access, code was my first choice early on and I wrote a lot of useless code and misused events also. Watch at least one of the videos to give you a feeling of how the form that displays the events as they run is working.

 
I could ditch whatever other scratch-like language they were using 😅

You can start out with macros and then convert them to VBA it's not a very clean process and there is a gotcha which you should be aware of !!

More information on my website here :-

Extract :-
I discovered a minor issue when converting a Macro to VBA code. You may have to include the “Value” Property for your text box or combo box (whichever control the the macro is associated with) – this seems a bit odd to a seasoned Microsoft Access programmer because the value property is normally a default and you don’t have to add it

and here's the video :-

TempVars Value Error - Nifty Access​

 

Users who are viewing this thread

Back
Top Bottom