When I start developing in a VBA-enabled application, the first thing I do is check whether it includes a macro recorder. If it does, I use it to see what code gets generated for typical actions, and then adapt that code to fit my needs.
If there's no macro recorder, or if I need to go beyond what it captures, I start by adding some basic elements manually and observing how the application object handles them. Inspecting the application's object model through the Watch window is especially useful for that kind of discovery.
Once you've interacted with the app manually as intended, it's just a matter of expanding nodes in the application object tree (from the Watch window, the debugger) to see where things are defined. When I spot relevant properties, I play around with them to understand how they behave. After that, I look into the available methods to see what functionality I can tap into.
This process is pretty consistent across Microsoft Office products. However, some applications may require approaches that feel unfamiliar, especially if you're coming from an Access background. In those cases, there's usually a bit of learning involved. For example, some methods may expect arrays as parameters, like in AutoCAD (not a Microsoft product, but also VBA-based).
Other methods might require you to define a variable first, because that variable is expected to receive something. In some cases, you'll need to create and configure one or more objects beforehand just to use a method at all.
Once you have a working piece of code from within the application, you can automate it from another VBA-enabled program using pretty much the same code, simply by swapping the local application object with the external one, using either early or late binding depending on what suits the project.
