The reason why my flowcharts were so messed was that OOP inherently has a lot of recursive programming, as BassplayinMacfiend has said, there's a library for you to call upon.
However, I decided an outline would work better. Realize it's more of a pyrmaid, so as you work downward, you may have to branch out as if it was a nested loop, until it's satisfied, return to the question you left at and continue until all questions are answered.
Remember this is from my frame of reference of Access so I would want to check with other programmers to see if they can agree with the process.
Code:
1. what do I want on the screen?
i. What do I want user to do there?
1. What can user input?
2. What conditions must be satisfied before user moves away?
ii. What commands user can enter? (see 1.i.1)
iii. What menu or options user can have?
iv. What do I want the computer to do there?
1. What conditions should be satisfied before it loads?
2. What should computer know about it? (variables, objects, events)
3. Should computer monitor user’s inputs?
a. What conditions should inputs satisfy?
b. What actions should the computer take to accomplish the purpose?
c. Should the computer prompt user for more details?
i. Do I want the details on same screen or a new one? (if no, a new screen returns to 1 as a nested loop)
So in a nutshell, instead of thinking how to order your code, think how you want it to behave. Kinda like homebrewing a puppy of your own.
