I have to admit I wasn't sure about your question. But a cursory search said you weren't talking about a product name that I could find. Therefore I think you are talking about a particular programming attribute or style.
In a sense, event-oriented programming in Access is a stepping-stone for the world of asynchronous programming. The other main way in to the asynchronous arena is the world of interrupt-based device drivers. In both cases, you set up some conditions to respond to events with little or no predictability of the timing of their occurrence. Then you sit around and wait until your asynchronous event occurs and your code kicks in. The trick is to not try to do too much in the async code when other things are going on.
Access is a little bit different from true asynch code because you don't write a MAIN segment. MSACCESS.EXE already has that honor and won't relinquish it. But - particularly if you have a form with a lot of command buttons or controls with special requirements - Access represents the right environment to "get your feet wet" on writing limited-response event-driven code. Access is not FULLY asynchronous because its sequences are well known and have been published - but YOUR event-related code is that entry point to the concept.
At deeper levels, device drivers have to accept inputs from programs (perhaps to trigger an I/O call). They have to field an interrupt when the device signals one. They have to stage the process of notifying the program in question that the operation is complete. They might have to transfer data from system-internal buffers to program buffers. They might have to operate in elevated CPU priority environments that have implied limits on exactly how long the code can stay at elevated priority. The data flow logic can be daunting when considering how you can exchange data and control from kernel-level code to user-level code and still maintain continuity and responsiveness. But that is the nature of asynch programming that has to co-exist with a synchronous environment.
As to your use of the forum, don't worry about it too much. I don't speak for others, but I have seen the topics of your questions over the years you have been here and I see someone seeking a "home" - not in the sense of a place to live, but in the sense of a home for your career. You have a thousand ideas but things don't seem to be working for you. I'll give you advice that my uncle gave me when I was a teen-ager. Try to decide what you like to do and learn how to make that a career. If you do, you will never actually work a day in your life. At least, it won't seem like work. Step back and think about what you enjoy. Then try to find a way to turn that joy into a job that will support you. Don't ever expect to be wealthy. But expect to be satisfied.
When I faced that choice, I realized that I liked taking someone's problem specifications and making the computer do what was needed, even though the original problem wasn't so easily transferred to a computer. Admittedly when I made that choice 50+ years ago, the direction I took wasn't common. I became a middle-man who could deal with the science of a problem AND the technical / engineering solution to the problem. My first industrial job was to be a device driver specialist - standing between the computer and the real-world problem to handle the interface devices for an oil-and-gas pipeline with physical property monitoring sensors to track the state and content of the pipeline. Sort of a real-time instrumental analysis situation, just right for an instrumental analysis chemist.
