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 !!!!!!!!!!!

wow... 80+ views and not one single reply.

I find it easier to know what would be the hardest part of the program, then make something that would solve that problem.

also before asking a question on the boards try searching. not just these boards, but on google.com as well. unless you are asking for stuff that is impossible to do in VB w/o external dlls, you should be able to find it.

I think the idea was not to reply. It said read.

Quote:

---

Originally posted by DiGiTaIErRoR
I think the idea was not to reply. It said read.

---

oh you couldn't be more wrong :D

Quote:

---

Originally posted by kropes
Ok, if anyone has any more comments or such to this.. please feel free to add them in.

---

How will a flowchart help me program something I dont know how to program lol.

Quote:

---

Originally posted by Phade
How will a flowchart help me program something I dont know how to program lol.

---

it will help you learn programming and structure of a program and how does a program work...

CHAO...

Too bad a flow chart can't help me think of something to program. :( You need to at least have an idea before you can make a flow chart of what you want it to do... hehe. We use flow charts all the time at my work, usually for programming, sometimes other things.

Oh well, reading the whole thing wouldn't of helped anyway.

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.

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*

I have to agree with Wokawidget about the help provided.

I taught myself VB about 5 years back, from the help provided. Within weeks I had created a decent app with an explorer style front end connected to an access database. Everything I needed was supplied free in the help.

Also I have to say I find flowcharting (or at least pseudo code) really useful when I'm trying to get my head around some difficult functionality I have to fathom out.

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,

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

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.

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.

---

Maybe nobody uses flowcharts and algorithms in real life, especially when VB is hailed as a RAD tool :rolleyes: but after seeing some posts on the forums, one is surprised to find that there are absolute newbies out there who are asking questions. Now there's nothing wrong in that exactly, but the thing is these newbies don't know even the basics of programming in VB, or adding forms, modules and class modules to a project and such basic stuff.

Apart from the above piece of advice about learning programming the right way, the members should also make it a point to explore on themselves and only then ask questions here. People seem to be asking questions here just because they are too lazy to do it themselves. One example I can recall immediately is the number to word code. Anyone with a basic intelligence can write this piece of code, and the posters were probably only trying to save some sweat themselves, grab the ready code off someone's post and make their day.

And if you are out to write such a piece of code, it would be much better if you knew something about structured programming, or that programming is the art of arrenging lines of code in a meaningful sequence :rolleyes:

.

I think whatever language your going to program in you must first have some idea of how you want the system to work. If you don't have this, then....urmm

I totally agree with the poster. It's a lot easier to map out the flow of the program first than it is to actually go ahead and start programming. I am about to take on my first real VB project and I have not used VB for about 3 or 4 years. I have a very steep learning curve because it has to be finished in about 3 weeks.

If I don't flow chart it first then my head will explode. I am sure of that.

I agree flowcharting, or some sort of outlining helps me tremendously. Some people are able to think in very wide spectrum that allows them to, sort of, see the project already charted out. However, some others, such as myself, think more like my boss says, on a one lane highway. We are not able to see the things that will be affected later in the project by the code we're writing now.

I began learning sort of like techgnome said. They said here's the computer, here's a book, and here's what we want. I asked many of those dumb questions myself (not too far back). I still do if I'm pressed for time and I think someone can help me right quick. But now that I am aware of the resources available I rarely have the need to ask a question now, and I'm not 1/10 the level of half the people on this fourm. But from threads like this one I learned how to answer most of my own questions, (and I bought a better book!).
So let me take this opportunity to apologize for all the stupid things I asked, and thank everyone who has ever helped me, and thank everyone who has posted things like this thread that taught me to research first..

by the way BuggyProgrammer is right google.com is an awesome place to search (after searching the forum good)


JO :D

I agree with Kropes, there are way too many posts from people who don't want to take the time to learn or want some else to do the work for them. I understand that there are circumstances where time is of the essence, but I have seen too many posts that start like: This is what I want to do, can you write all of the code for me.

It seems that I am in the same boat as many people here. I have been programming for a couple of years now and was kind of dumped up to my neck with this project. Prior to working on my current project I had never really programmed before (except for the regular school assignments). What little programming I did know was in Fortran and Pascal. When I accepted this assignment I thought I was going to be part of a team. Much to my surprise I was the project (Hardware, software, test and documentation). My boss did not seem to mind that I had never programmed before, did not know VB and never even used MS Access before. His only advise was "F1". I have learned a lot over the last couple of years, but relatively speaking I do not know much at all. My learning has always been a direct result of my current needs and the whimsical desires of my users. For me personally, I find that I learn things better if I figure it out for myself. Unfortunately, sometimes my methods are just plain dumb.:o Many times I have been reviewing posts and came across one which many people may have considered as a very basic question and I read the responses and realize just how dumb I had been in doing it my way. So, I do not feel that there too many questions that should not be asked. Just that people should attempt to find an answer prior to posting.
Sorry, I have been holding that in for a long time.:D

As far as Flowcharting goes, I think it really depends on the programmer and the task that is involved. When I first started, I used flowcharts all the time. Now, I only resort to using them when the task is very complex and may have a significant impact upon the rest of the application.

First let me say this is a great thread for newbies to read because there are alot of basic (pun certainly intended) questions asked here and alot of professionals trying to have their code written rather than working together with the board to come to a solution to their problem. For one thing when somebody posts code for you and it doesn't work, READ IT, try to figure it why it didn't work, alot of times it just comes down to a typo or a control you didn't have on your form or that control was named differently then your own. When all else fails post what error happened, what line of code the execution stopped on and what you tried to do to get it to work. Basically try to learn something from the collective minds here, not just steal there knowledge and take credit for it later.

As far as documentation is concerned, I don't think it is absolutely necessary to use flowcharting just some sort of documentation. Pseudocode seems to be the best thing to me because it breaks it down to the thought process of the user and how he will be using this program. If you do end up using flowcharts I think you should have a look at UML, basically it is a way of flowcharting that specifically targets object oriented software design.

I use very simple flowcharts and they are extremly helpful. I have noticed when I try and detail the chart too much, I get really confused.

Also, I agree that there are some people on these forums that need to read the book, "The Art of Thinking".

Someone posted a thread the other day that said:

Quote:

---

I need to convert twips to pixels... forgot how yah do it.. THANKS

---

I responded and told this user to use Screen.TwipsPerPixelX and/or Y.

This user responded back and said:

Quote:

---

how do you figure that gives me the info i need? If I have 5000 TWIPS and i wanna know how many PIXELS that is.. then Screen.TwipsPerPixelY isnt gunna help

---

So I responded with:

Quote:

---

Sure it will.... you are just not thinking about it. Pixels is pixels and twips is twips.

Screen.TwipsPerPixelX will return to you how many twips are in the pixels on your screen.

myvar = screen.twipsperpixelX

5000 / myvar = the info I need to know!!!!

WOW!!! Now you can get out your calculator and check the math.....

---

I've been programming for 35+ years and I still occasionally flowchart difficult pieces of code. When I do it the other way around (code first --> get frustrated --> flowchart --> recode) I often find that the resulting code is more compact and easier to understand than the original code.

Quote:

---

Originally posted by MartinLiss
I've been programming for 35+ years and I still occasionally flowchart difficult pieces of code. When I do it the other way around (code first --> get frustrated --> flowchart --> recode) I often find that the resulting code is more compact and easier to understand than the original code.

---

Same, but i've only been coding for about 2yrs :)

We were taught to use flow charts and data flow diagrams and system chart thingys and all that in software, which are useful but it depends on what your doing, a gantt chart seems useless to me.

I usually will stare at my screen for 30mins-1hr before starting a program and think about it but I've never made a flowchart. I've tried though, it ended up just being a doodle in the end though of some super program that didn't have anything to do with what I was really doing.:)

Flowcharting most of the app makes things easier when you begin programming. It allows you to see how things will interact with each other, and make notes to yourself to allow for ceratin situations, whereas, without the chart, you might either forget, or find yourself reprogramming alot of code becuase "now I remember".

a picture says a thousand words, right?

i tend to use my own form of flowcharting/pseudo coding and several pictures when i plan out a more difficult piece of code.... I like to plan out every aspect of things, and how each thing will work and affect every other thing... yes, i do use pictures, sometimes pictures of what the interface should look like even... i find that if i know how i'm going to make the interface, i can figure out a good compact way of coding things....

so, i start by building the interface.... usually an efficient interface design reflects efficient code design, and vice versa...

Most replies from "programmers" who do not use or understand flowcharts appear to be missing the point.

I learnt to program originally using C before the days of windows and OOP. It was very important to clearly define what you were intending to program and understand the process before creating code. Anyone, given enough time, can create a VB program, but if the program is sucessfull and evolves over a period of time, a Flowchart is the only real means of tracking the evolution of the program and especially if a programmer has to return to the code after a period of time.

I would strongly recommend the use of a Flowchart, no matter how big or small the program is.

well guess what? My idea doesnt include flowcharts.
When you get a big project, it might seem daunting. Ive undertaken many programming tasks that i thought "how in the heck am i going to do that?" The easiest way for me is to take it in small chunks. Write subroutines that i will use in the program first - you know - custom functions, etc. For example: If i was to make a program that would fade color text for html for example,
i would write a subroutine to convert rgb to bgr and vice versa,
another for calculation of new colors based on the first and last colors and the number of steps required to fade them; another one to generate the new color string in html code, etc.
once all the basic functions i will use are there (and debugged with liberal testing code), it is usually pretty easy to just insert 20 or 30 finish lines of code that all they do is call functions on button clicks, etc.

Unfortunatly, it isn't always that easy. Take the current project I am working on. It reads in a file (flat, each row is different depending on the row type - header or detail-, no delimiters - yech), validates some information in each row, then stores it. Upon user action, the data is then transformed into data used by the Accounts Recievable part of our system and posted to the customer's account. Seemed simple enough. But to truly get my arms around it all that needed to be done, I had to create a flow chart. And it turned out to a be agood idea that I did. While showing it to the proj manager, he noticed a small flaw. The file can contain multiple header rows, each w/ corresponding details. If any ONE of the details fails validation for any reason, THE WHOLE GROUP must be rejected. He was able to spot this in 5 seconds, just by looking at the flowchart. That, coupled w/ the database design document, is going to make it easier on me when it comes time to write the code and I have to decide "Ok, this piece of data goes here." And it will also ensure I have all the data pieces I need to post the transactions to A/R.

Muzzad !

Quote:

---

Most replies from "programmers" who do not use or understand flowcharts appear to be missing the point.

---

Thank you !

For all of you that say that flowcharting is a waste of time, you never do it... basically you are saying "you are to clever and to intelligent" to resort to something so fundamental.

it also tells me rather quickly the people that have been programmers for 5 years or less, or have never work in a large installation. you ask anyone that has been programming for a long time, and they will be the first to tell you how many times flowcharting has been a life saver (or a marriage saver.) wait till you guys get about 100 LARGE scale projects under your belt, then be asked to go back and work on something you have not touched in about 5 years. "all we want to do is change this thing here." (run for the hills !)

sure, be my guest.. go back and read through all of the code, and learn the process all over again. when instead if you would have simply documented it and flowcharted the process to begin with, you would go.. "ok, you want the function inserted here ?" (point to it) "ok, it will effect all program paths from this point forward. these are the items that will need re-validating before we can be sure that it works properly."
or you can sit there and read through the program, line by line... and eventually come across something and think to yourself "what the hell was I thinking.. what the hell was I trying to do here ?"

oh, so your going to be REALLY intelligent and just remember everything, cause of course you are so smart...
well the project you are now fixing, is not yours (anymore.) it has been "updated" about 75 times over the past 5 years... by about 15 different "programmers." of course they were all really intelligent too, and none decided to make any flowcharts. now the program code that you are staring at, at 4 am while your girlfriend/ wife/ husband is wondering where the hell you are, looks NOTHING like you remember it, in fact, most of the stuff you were looking for, cant even be found because some other "intelligent" programmer decided it was to confusing and he was going to "simplify" it. hope you have PLENTY coffee and a good explanation to the company president as to why this new feature they promised the customer, is not ready on time.

where I currently work, (a medical research facility) I am 1 of 250 people in the IT department at my site, about 450 world wide... at any time I am expected to be able to go into just about any of the 15,000 programs we have installed and be able to make changes to it. on "critical" incidents our response time to make a fix is demanded to be less than 8 hours. No exceptions.
tell me if you think our organization uses flow charts ?

when we make proposals for updating a process, improving something, or simply fixing something. one of the first questions management asks is "what impact does it have on the rest of the system"... the rest of the system being any one of those 15,000 other programs. management is not going to read through thousands, hundreds or even just 10 lines of code to see that what you are doing is going to address the issue. they want to SEE what you are altering and at what point it is going to interact with the rest of the process.

For all you guys that never used flowcharts before. You want to get a raise at work ? get a promotion ? Or just get some well deserved recognition ? take some bizarre complicated process that you have that does not have any flowcharts and do a complete flowchart of it. Every detail that you can, flowchart it. Show every detailed step of the process.
Someone in management will look at it and immediately find something they have been wanting to address for years. But could never quite determine where the bottleneck was, because they themselves never really understood the entire process and all of the events that has to happen to do what would seem to be even the simplest things.

Flowcharting is NOT just about designing your “Hello World” beginners applications.
Flowcharting is about saving yourself thousands of hours re-learning things you already did before. About saving your company possibly millions of dollars in lost money from processes that are not efficient. About saving yourself from going gray early while you try to understand some “simple” program some other “intelligent” programmer developed that is no longer working for your company.

Flowcharting is about having some REAL documentation on hand for the thousands of reasons you would want to… like worst case scenario: Your wonderful program was hit with some new UGLY virus, all backups and source code are infected too. You have to rewrite it from scratch.
Having a little trouble remembering what that process was again ???
Have fun !

Oh, by the way, this has to be done In 8 hours because that is when the doctor will be back in the hospital to evaluate the statistics on the blood and tissue samples that your company is processing for them. He needs the information to determine if he has to perform emergency surgery to remove a kidney from someone and stick them on dialysis.

You have 480 Minutes left… Ready ? GO !

Flowcharts are about resolving REAL issues.

High-five to Kropes and a "Hoo-yah!"

yeah thats all well and good and ill admit ive never tackled a project someone else has helped on. But all the flowcharting in the world wont help you if you dont name your variables, functions, and subroutines descriptevily. a = 5 is confusion waiting to happen. AgeOfMaturity = 5 is better.

Thats what data dictionaries are for.

They list all varibles, there type and areas used etc.

To Kropz and others who picked at me:
I was saying flowcharts are waste of time if it was only me involved in the whole project and there was no boss or anybody helping me with it. In that case, I remember what I coded because it was all my idea so, again, no need for flowcharts if the whole procedure is in your brain.:)

Learning to program by using flowcharts is a bit like learning to ride a bicycle with stabilisers...

At first they seem to help you out, but after a while they only slow you down.

I've never used them in anger, and I've never felt at any time that I wished I'd used them. Even when I've dumped an entire application cos it was going the wrong way.

I agree with those people that say they don't always know how their program idea should be implemented in a flowchart, and reckon that if you're in that position you might as well just start coding, and sort it out as you go along.

Nobody produces an application that has not had some kind of "tweaking" during its development!

abdul - still doesn't hold water. I've worked on things where I was the only one in that part of the system. Then go back in there 6 months later, and I have flippin clue what I was thinkning previously. I look at some of the stuff I've done and go "What the....." I basically then have to go back and re-learn what it was that I had done. Not always easy.
Now, if you are the only one on a project, no one has ever touched it, and no one else will... if your memory is that good, then so be it.......
Some may call it job security, but .... to me it just doesn't make sense. What if your company gets bought out? or there are layoffs, or...... what ever.

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

I've locked this thread because I believe there is enough discussion here already for people to decide if flowcharting is a good idea or not.