An Easy way to LEARN VB (all should read !)
Hi Gang… I feel obligated to write this… I am seeing a lot of questions on here that … well… sorry, but seem really basic and fundamental…. I am 35, I have been writing software for 21 years, I can program in 7 languages….so please forgive me for coming off that you guys just learning are asking dumb questions… NOT AT ALL ! just, if you never had any formal training with it, or have never had someone tell you how to go about learning it quickly… I know its really hard… SO…..
I am writing this to try to give you guys a heads up and some tips on this programming thing… this is all info based off of how I learned how to do it… about 2 lifetimes ago…
So here are SOME of my tips and information :
<B>1) FLOWCHART !!!!!!!!!!!!!!!!!</b>
“Flowcharting is a tool for analyzing processes. It allows you to break any process down into individual events or activities and to display these in shorthand form showing the logical relationships between them. Constructing flowcharts promotes better understanding of processes, and better understanding of processes is a pre-requisite for improvement. “
You can not begin to imagine how much simpler it is to write a program when you have a complete flow diagram of what your plan is for the program to function. PLAN it… over the years I have seen way to many people sit at a computer and try to think as they go… “now, here’s what I want it to do” after about the first 30 lines you realize that you need to go back up to a different area and add something back in. after about the 40th line, you realize that what you added in makes more sense if you put it someplace else…
after you created your 3rd form, you realize that you need to change the order of the first form around because you forgot to put in a field, and without it on the first form, the 2nd and 3rd don’t make a lot of sense…
Flowcharting has become a lost art… it is possibly the single most important part of designing software. (read that again…)
You sit down with a paper and pencil, or whiteboards and a dry erase markers (I have (3) 4’x8’ whiteboards on my walls in my office, lines and boxes drawn all over them with flow diagrams) and you go step by step and design a flow diagram of what you are expecting the program to do. This is a high level design… you are NOT putting VB code down… this is a step to think the process through…
But let me put it this way.
If you know what you want to accomplish… you should be able to design a detailed flow chart, give it to 10 different programmers from 10 different programming languages never discussing anything more with them, and get back 10 programs that all do the exact same thing. The Logic of a flowchart does not care what language the program will be written in, it is simply a step by step set of instructions for you to write the program.
Writing a program is like baking a cake… you have to do it in the right order.
http://www.wiley.com/college/busin/i...ides/algor.htm
Like Driving a car, you need to know what the SIGNS mean.
http://www.wiley.com/college/busin/i...es/symbols.htm
And when you going to a NEW place you have not been before. It helps to WRITE DOWN THE DIRECTIONS ! hehehehe
http://www.wiley.com/college/busin/i...des/pseudo.htm
pseudo code is a plain English version of what you are trying to accomplish.
Some GOOD Detailed explanations of flowcharting.
http://www.smartdraw.com/resources/c.../tutorial1.htm (first 2 pages are good, but the rest are a sales pitch)
http://www.hci.com.au/hcisite2/toolkit/flowchar.htm
http://home.att.net/~dexter.a.hansen.../flowchart.htm
http://quality.enr.state.nc.us/tools/flowchart.htm
<B>2) Don’t be afraid to experiment...</b>
Save your file just before you implement a major change, make a backup of the project, just incase you start changing things and break something and cant finger out how to fix it.
Worst case scenario… if you really fuddle things up, just reload your backup copy of the project or form.
<B>3) Learn What Is Available and What the Capabilities are :</b>
In the help files there are a list of reserved words, commands, vbVariables (like vbCrLf, vbTab. etc....)
different items are grouped by the type of data manipulation you want to do...
all string functions together...
all numerical functions..
all operators... Etc…..
The best way I learned how to do programming was take each and every command, read the description for what it is used for., and write a 1or 2 line program just to see what it does. even if you do not have a good use for it right now... at least you are aware that the command is out there. It is SO much easier to do something when you answer the question of “How Do I (do this function)” than it is to answer the question of “Can I (do this function)” if you know what the capabilities are all you have to then do is be able to look them up again. If you do not know what the capabilities are, you will forever be swamped with questions like “can I “
Ok, if anyone has any more comments or such to this.. please feel free to add them in.
I hope this helps some of you, I know without doubt that if you plan things out first, it will make such a bizzare difference in your projects.
GOOD LUCK !!!
Aaahh. Forget I said that…
GOOD SKILLZZZZZ !!!!!!!!!!!
Chimpanzees and a large tin a red paint...WAHT'S GOING TO HAPPEN?!
Quote:
Originally posted by abdul
Flowcharts are good when your programming teacher asks you to create one for your easy-boring-hello-world or some other newbie program. I have never used them in reality because it's just waste of time and it doesn't make a big difference either.
I have to agree with you there :D
Never used a flow-chart in a real world application.
I learnt VB from scratch 2 years ago. I am now a well paid VB programmer. The way I learnt VB was by:
[SIZE = 25]
Pressing F1
[/SIZE]
It is so annoying when people don't even use the help provided, which is good enough to learn from to become a VB developer...*SIGH*
Break down - - - Not the nervous variety
Don't know about everyone else, but I find that Word is really useful for breaking down the structure of what I'm going to do.
1. Type in the core elements of your job in a list form, one under the other.
2. Move between each one and indent, then break down each task into subsections something like...
Code:
Write program
Create forms
Insert controls
Code Controls
Create Modules
API module
API to calculate lack of pay...
And so on. I find it much easier than flow charts. It's also useful to, say, colour the line(s) a different colour for the section that you have completed.
I also use a home grown versioning tool within Access databases that I write, giving details of how complete a particular task is etc.
Regards,
Up 'ere we eat sheep dung...
Isn't that just a list of things to do?
- Get up
- Switch off alarm clock
- Remember where you live
- Work out if you have work today
- Go to work
- Try and figure out what code you wrote yesterday and decide it makes no sense
- Rewrite code
- Pretend to look busy
- Eat raw fish
- Go home
- Eat more fish
- Rock around the fish till you go to bed...
Personally I prefer Notepad :D
Re: Chimpanzees and a large tin a red paint...WAHT'S GOING TO HAPPEN?!
Quote:
Originally posted by Wokawidget
I have to agree with you there :D
Never used a flow-chart in a real world application.
I learnt VB from scratch 2 years ago. I am now a well paid VB programmer. The way I learnt VB was by:
[SIZE = 25]
Pressing F1
[/SIZE]
It is so annoying when people don't even use the help provided, which is good enough to learn from to become a VB developer...*SIGH*
I agree w/ Wokawidget, my induction into VB came in the form or "Here's the install disks, there's your machine over there (being used litteraly as a doorstop), you'll have to scrounge for a mouse though." And that was it. I was on my own. And this was before the days when we had internet access or even MSDN for that matter. I learned via trial and error, and reading books.
Quote:
Originally posted by abdul
Flowcharts are good when your programming teacher asks you to create one for your easy-boring-hello-world or some other newbie program. I have never used them in reality because it's just waste of time and it doesn't make a big difference either.
I dissagree.... there have been several times in the last few weeks when the flowchart saved my arse from going down the wrong road. Almost everyone can understand a flowchart. Even non-technical people. I find it the most effective way to communicate and determine what needs to be done and the process in which it needs to be done. The client then has the ability to say, "No, that's not quite right. At point X, we need to goto point D, not M. ...."
Overall, we use flowcharts pretty haphazardly around here. But when we get into the deep stuff, the first thing we do is break out Visio and start plopping down objects.
I haded flowcharting when I first learned it back when. Now, I don't know what I would do with out it. I'll admit, that there are somethings that would be a waste of time flowcharting ("Hello World") but other things I would have spend MONTHS developing if it weren't for flowcharts. And the developer who comes along after me to do maintenance will be grateful the process is charted out.
Novell is poo...They blocked MSN!
If no-one else can understand how your program works, ie if you use complicated API as well as not having flowcharts then this makes you indespensible from the company :D