I've been trying to learn VBA since last week. I bought multiple books and studied many codes that's written on the website. However, I feel that I did not make any progress. I know that VBA is not something you can learn overnight. But I feel that I didn't progress at all!
Give yourself 2 months and then see how it goes. One week is way too short of time to make a valid assessment, especially if you are just starting out.
Coding isn't something that you learn theoretically from a book and say "Now I know how to code". It slowly infuses into your mind through experience and above all persistence.
Indeed taking too broad a swathe in the beginning can be really disheartening because it looks insurmountable. I suspect this is where you are at currently.
You come across so many disconnected things at first and it is hard to see the big picture but eventually the ends start to join together.
As Bob says, after a couple of months you might begin to get some idea but you will still be far from fluent. Keep at it. It is very satisfying the first time you write a piece of code that works.
as well as understanding the techniques of coding, you also need to appreciate the nuances of coding for access (windows).
originally programmes were single monolithic blocks of code. The programmer dictated every action that a user could take. With windows apps, it's different. Each event is like a little applet, and all the events hang together - so the programer has to understand how actions/events can interfere with one another.
Yes, you can stop this by making every form modal, but that isn't a great idea.
It's like the difference between a "linear" game that forces you to collect objects/complete taks in a set order, and a "free-roaming" game where what you do may be affected by things you didn't do, and didn't know how important they were.
Maybe try a VB primer, rather than an Access primer, to get VB skills
-----
but eg, take something simple - you want to enable a control based on the value of another control
so you say perfectly correctly
Code:
if control1 = 4 then
control2.enabled = true
else
control2.enabled = false
end if
but this can be replaced by this not so obvious version, with an implicit boolean comparison
control2.enabled = control1 = 4
So gradually you build up a knowledge bank of stuff - and your programmes work better, are more resilient, have better error handling
And then you look at stuff written by real aces, and many of us just stand back and wonder (well I do!). It is real hard sometimes to understand how some tricks are accomplished, even with the code to look at.
Further to the helpful comments from others, I'd recommend working on a small "defined" problem and working through it. It's easy to lose focus when you're "just learning" and reading several concepts/approaches. It just seems too vast.
Further to the helpful comments from others, I'd recommend working on a small "defined" problem and working through it. It's easy to lose focus when you're "just learning" and reading several concepts/approaches. It just seems too vast.
I totally agree with this. I got kinda pushed into learning VBA. I've had no training at all. Started out helping out with data entry and ended up building forms, queries etc. Now i'm getting into vba. As my boss tells me, don't re-inevent the wheel. If there is some code already written that does something similar it can probably be made to do what you want it to with just a little tweaking. Good luck with it.
As my boss tells me, don't re-inevent the wheel. If there is some code already written that does something similar it can probably be made to do what you want it to with just a little tweaking.
That is so true and a good skill to have is learning how to do a good search for something; learning the right keywords to put in and all. But if you do use someone else's code, it is good to make sure to leave a credit to them in your application.
Next remember that VBA is like turning on a switch, or starting your car, or maybe setting the thermostat and timer of a microwave oven.
In other words, in VBA, an event triggers an action.
So when I click a button, my car starts. The actions is what you tell it to be, based on something happening.
Next, create a database from one of the built in wizards that is similar to what you want to build, open the forms, queries and reports. Use the system, then open it in design view and learn how they did those things. The North Wind Database has many built in features to look at.
And last, you must have a specific need; it is very hard to learn without a goal in mind.
The last point is a good one - when I first started, one of the sample DBs was a CD catalogue.
it showed a CD form, with a subform of a track listing. The CD form had a total time - and at the time I couldn't work out how to get the total time on the main form.
And when I investigated how MS had done it .... they hadn't. They just had a separate field in the header table for total time!
So my first DBS was a DBs to track golf scores. Master table with round history, and sub tables with performance at individual holes. Fairly self-contained, but definitely not trivial, and very instructive.
Fundamentally VBA is incredibly simple. It really just involves controlling the execution sequence using logical operators and loops.
The complex parts are the object models that these operations act upon and knowing how to refer to them. When you start out doing VBA in Access you are mainly exposed to the Form, Report and Control object models. These are what you interact with in the Form and Report Class Modules when you create an Event Procedure.
Gradually you build a knowledge of the Properties and Methods of those objects and learn how to enumerate them.
You also notice you can issue commands in those procedures and these are at first a little mysterious. Why do they all seem to have dots in their names?
It starts to make sense when you see them described in terms like "Methods of the DoCmd Object" and it begins to dawn on you that these ostensibly intangible "Objects" (the bit before the dot), their "Properties" and "Methods" (after the dot) are really central to what programming is all about.
Then you realise that the Application, Project, tables, fields and queries are all objects too and become familiar with their Properties and Methods (their object models).
Then you find that all the Office applications and their componets have object models. Then you see it in webpages and even Windows itself. Object models are the core of interacting programatically on computers and it is a vast subject. They all work with different language dialects and have their own idiosyncracies but the underlying principle of the object model is universal.
At some point you discover you can build your own objects with custom properties and methods too.
Happy learning. Stick at it because it is very rewarding when you get your head around it.
Thank you! You guys are right, I am looking at different VBA books and trying to understand everything. I guess that was my first mistake. I will start smaller. My objective is to understand the code so that I can tweak existing codes. But you guys are awesome!
