Tips & Tricks #0003
Have you ever wished you had named a Visual Basic control by another name—or come across a project where the original programmer accepted all of the default control names—such as Command1, List1, Text1, etc.
Changing the name of a control is easy---you just need to open up the Properties Window for that control and change the Name property. However, what happens to the code associated with that control won’t make you happy!
The code seems to disappear---in actuality, any event procedure associated with the originally named control is relegated to the General Declarations Section of the form. As a result, when you run your program, that code is never executed.
So how do you “get the code back”?
The code hasn’t really gone away---all you need to do is find the event procedure in the General Declarations Section of the form—and then change the “control name” portion of the Procedure header to the new name of the control.
For instance, if you had this code in the Click Event procedure of a Command Button named Command1…
Private Sub Command1_Click()
Msgbox “I love VB”
End Sub
and then renamed the control to cmdOK---VB ‘moves’ this code to the General Declarations Section of the Form.
All you need to do is modify the procedure so that it looks like this…
Private Sub cmdOK_Click()
Msgbox “I love VB”
End Sub
Now, VB will once again associate this code with the command button---and when you run your program, the code will execute---just like before.
By the way, some of my fellow programmers rename their event procedures prior to changing the name of the control. Either way, the effect is still the same---the code will be associated with the newly named control.
Monday, May 29, 2000
Monday, May 22, 2000
Developer Career Tip #0003---Learning Visual Basic---Part 1
Developer Career Tip #0003
Learning Visual Basic---Part 1
I'm often asked my opinion as to the best way to learn a new programming language.
The answer to that question depends on many factors: Do you already know a programming language? How much time do you have to learn one? How do you learn best?
Are you one of those people who learn best in an instructor-led classroom environment? Can you read a good book or books on a programming language and learn that way? Can you benefit from an online learning experience, where you can take advantage of an instructor or mentor who can answer questions if and when you have them?
In this article, I'm going to examine the classroom environment, and in future weeks I'll be discussing self learning and online learning.
As far as classroom instruction, one alternative is to take a Visual Basic course at a Microsoft Certified Technical Education Center (CTEC).
(For more information on Microsoft Certified Training, check out this web site: http://www.microsoft.com/train_cert/)
There are two main advantages to taking a course at a CTEC.
First, you are assured of taking a course developed by Microsoft and part of the Microsoft Official Curriculum (MOC). MOC courses can only be taught by a Microsoft Certified Trainer (MCT), who must be certified in the subject matter he or she is teaching, and must demonstrate the instructional skills necessary to deliver the material. Secondly, these courses do a good job of preparing you to take the corresponding Microsoft Certification Exam in that subject.
However, there are also disadvantages to the CTEC alternative..
First, the courses are expensive. For instance, you can expect to pay approximately $2000 for a week long Visual Basic course. Secondly, the courses are geared toward computer professionals---so if you are a raw beginner, the material is likely to be over your head. Finally, the courses themselves are very intense, even for someone who has a programming background. For a Visual Basic course, you can expect to be in the classroom 7 hours per day for a solid week---and that can make learning difficult.
Next time---classroom alternatives to the CTEC..
Learning Visual Basic---Part 1
I'm often asked my opinion as to the best way to learn a new programming language.
The answer to that question depends on many factors: Do you already know a programming language? How much time do you have to learn one? How do you learn best?
Are you one of those people who learn best in an instructor-led classroom environment? Can you read a good book or books on a programming language and learn that way? Can you benefit from an online learning experience, where you can take advantage of an instructor or mentor who can answer questions if and when you have them?
In this article, I'm going to examine the classroom environment, and in future weeks I'll be discussing self learning and online learning.
As far as classroom instruction, one alternative is to take a Visual Basic course at a Microsoft Certified Technical Education Center (CTEC).
(For more information on Microsoft Certified Training, check out this web site: http://www.microsoft.com/train_cert/)
There are two main advantages to taking a course at a CTEC.
First, you are assured of taking a course developed by Microsoft and part of the Microsoft Official Curriculum (MOC). MOC courses can only be taught by a Microsoft Certified Trainer (MCT), who must be certified in the subject matter he or she is teaching, and must demonstrate the instructional skills necessary to deliver the material. Secondly, these courses do a good job of preparing you to take the corresponding Microsoft Certification Exam in that subject.
However, there are also disadvantages to the CTEC alternative..
First, the courses are expensive. For instance, you can expect to pay approximately $2000 for a week long Visual Basic course. Secondly, the courses are geared toward computer professionals---so if you are a raw beginner, the material is likely to be over your head. Finally, the courses themselves are very intense, even for someone who has a programming background. For a Visual Basic course, you can expect to be in the classroom 7 hours per day for a solid week---and that can make learning difficult.
Next time---classroom alternatives to the CTEC..
Monday, May 15, 2000
Programming Tips & Tricks #0002---Enforcing Variable Declaration in your VB program
Tips & Tricks #0002
In a previous article, I mentioned the importance of enforcing Variable Declaration in your Visual Basic program by ensuring that ‘Option Explicit’ is coded in the General Declarations Section of each module in your project.
Most high level programming languages force the developer to explicitly declare a variable before using it. Visual Basic is a notable exception. In fact, by default, VB’s installation leaves the Visual Basic environment in a state where variable declaration is NOT required.
After installing Visual Basic, immediately select Tools-Options and check ON
Require Variable Declaration
Selecting this option causes Visual Basic to insert this statement
Option Explicit
into the General Declarations Section of each module in your project. The result is that an attempt to refer to a variable in code without first declaring it results in a compiler error.
What’s the big deal, you might ask? Is there really a harm in leaving this option checked off? Suppose you use a variable in code that you haven't declared? Visual Basic is a programmer friendly language—won’t VB take care of it?
The answer is yes---VB will take care of it---but the price of a mistake on your part can be huge.
For instance, suppose you assign a value to a variable called sngUnitPrice like this…
sngUnitPrice = 13.48
and then later in your code you attempt to refer to this variable in a calculation, but accidentally refer to it by an incorrect name, for instance sngUnitCost (yes, it can happen!)
sngTotalPrice = sngUnitCost * m_intQuantity
You're expecting the program to come up with a valid price--instead, the result will be zero, since the value of the incorrectly named variable sngUnitCost is zero!
When you tell VB to enforce variable declaration, errors like this are caught at compile time---potentially preventing disastrous results form occurring.
In a previous article, I mentioned the importance of enforcing Variable Declaration in your Visual Basic program by ensuring that ‘Option Explicit’ is coded in the General Declarations Section of each module in your project.
Most high level programming languages force the developer to explicitly declare a variable before using it. Visual Basic is a notable exception. In fact, by default, VB’s installation leaves the Visual Basic environment in a state where variable declaration is NOT required.
After installing Visual Basic, immediately select Tools-Options and check ON
Require Variable Declaration
Selecting this option causes Visual Basic to insert this statement
Option Explicit
into the General Declarations Section of each module in your project. The result is that an attempt to refer to a variable in code without first declaring it results in a compiler error.
What’s the big deal, you might ask? Is there really a harm in leaving this option checked off? Suppose you use a variable in code that you haven't declared? Visual Basic is a programmer friendly language—won’t VB take care of it?
The answer is yes---VB will take care of it---but the price of a mistake on your part can be huge.
For instance, suppose you assign a value to a variable called sngUnitPrice like this…
sngUnitPrice = 13.48
and then later in your code you attempt to refer to this variable in a calculation, but accidentally refer to it by an incorrect name, for instance sngUnitCost (yes, it can happen!)
sngTotalPrice = sngUnitCost * m_intQuantity
You're expecting the program to come up with a valid price--instead, the result will be zero, since the value of the incorrectly named variable sngUnitCost is zero!
When you tell VB to enforce variable declaration, errors like this are caught at compile time---potentially preventing disastrous results form occurring.
Monday, May 8, 2000
Developer Career Tip #0002---Solidifying your Visual Basic interview—take your code with you
Developer Career Tip #0002
Solidifying your Visual Basic interview—take your code with you
About a year ago, a student of mine (let’s call him “Jim”) was called in to be interviewed for an entry level Visual Basic programming position for a major corporation in the Philadelphia area.
While a programming dynamo in the classroom, Jim had no real-world programming experience—and he told me that as the interview progressed, he felt that prospects for an offer were getting dimmer and dimmer. Although he answered effectively all of the questions the interviewer posed to him, he felt that he was getting nowhere in convincing the interviewer that he was right for the job.
Just as Jim believed the interview was about to wrap up, he was asked him if there was anything else he wanted to say. Jim calmly reached into his shirt pocket, pulled out a diskette containing a copy of the Visual Basic project he had turned into me for his class project, and handed it to the interviewer.
The interviewer popped the diskette into his PC, fired up Visual Basic, and for the next half hour, Jim and the interviewer discussed the project. Jim told me that he presented a ten minute overview of the project, and spent the next 20 minutes or so answering questions about the project. The interviewer seemed impressed with the project, and about a week later, Jim was offered the job.
Now don’t let me give you the wrong impression here—Jim’s project, while excellent, was hardly commercial grade. It was a very good project that earned him an ‘A’ in my class---but it was just that, a very good student project.
What Jim and I are both convinced got him the job was not so much the quality of the project—but the fact that he was able to discuss it, explain it, and critique it intelligently and enthusiastically with the interviewer for a full half hour.
That half hour discussion allowed the interviewer to see beyond Jim’s lack of professional programming experience---and realize that in Jim he had found an intelligent, highly effective communicator who could be an excellent team player---valuable skills in today’s job market.
Solidifying your Visual Basic interview—take your code with you
About a year ago, a student of mine (let’s call him “Jim”) was called in to be interviewed for an entry level Visual Basic programming position for a major corporation in the Philadelphia area.
While a programming dynamo in the classroom, Jim had no real-world programming experience—and he told me that as the interview progressed, he felt that prospects for an offer were getting dimmer and dimmer. Although he answered effectively all of the questions the interviewer posed to him, he felt that he was getting nowhere in convincing the interviewer that he was right for the job.
Just as Jim believed the interview was about to wrap up, he was asked him if there was anything else he wanted to say. Jim calmly reached into his shirt pocket, pulled out a diskette containing a copy of the Visual Basic project he had turned into me for his class project, and handed it to the interviewer.
The interviewer popped the diskette into his PC, fired up Visual Basic, and for the next half hour, Jim and the interviewer discussed the project. Jim told me that he presented a ten minute overview of the project, and spent the next 20 minutes or so answering questions about the project. The interviewer seemed impressed with the project, and about a week later, Jim was offered the job.
Now don’t let me give you the wrong impression here—Jim’s project, while excellent, was hardly commercial grade. It was a very good project that earned him an ‘A’ in my class---but it was just that, a very good student project.
What Jim and I are both convinced got him the job was not so much the quality of the project—but the fact that he was able to discuss it, explain it, and critique it intelligently and enthusiastically with the interviewer for a full half hour.
That half hour discussion allowed the interviewer to see beyond Jim’s lack of professional programming experience---and realize that in Jim he had found an intelligent, highly effective communicator who could be an excellent team player---valuable skills in today’s job market.
Saturday, May 6, 2000
Developer Career Tip #0001---Clarifying Microsoft’s Certified Solution Developer Certification
Developer Career Tip #0001
Clarifying Microsoft’s Certified Solution Developer Certification
Recently I received an email from a reader seeking a clarification on Microsoft’s Certified Solution Developer Certification. In it, she asked if it’s possible to achieve the MCSD by concentrating only on Visual Basic.
If you’re considering getting Microsoft’s Certified Solution Developer Certification, you might be happy to know that it is possible to achieve this certified developer status by concentrating only on Visual Basic.
To become a Microsoft Certified Solution Developer (MCSD), you must pass three core examinations: Desktop Development exam, a Distributed Development exam, and Solution Architecture exam. You must also pass an elective examination.
For the Solution Architecture Examination, you have no choice---you must take the grueling Analyzing Requirements and Defining Solution Architectures (70-100).
Within Desktop and Distributed development, there are a variety of ‘tracks’ that you can pursue: Visual Basic, Visual C++ and Visual Fox Pro. If you intend to pursue the VB ‘track’, you can take the Visual Basic 6 Desktop Examination (70-176) and the Visual Basic 6 Distributed Examination (70-175) to fulfill your three core examination requirements.
As for the elective examination, there are about twenty or so to choose from, including the Visual Basic 5 exam.
Yes, that’s right, Visual Basic 5. Visual Basic 5 is still a supported Microsoft package, and I work with many companies that are still using it. The Developing Applications with Microsoft Visual Basic 5.0 (70-165) examination is available to take as an elective---and if you are like many Visual Basic programmers who have been using it for many years, you may find this examination to be a piece of cake.
Many MCSD candidates are under the mistaken impression that once you have taken two Visual Basic exams you cannot take another Visual Basic exam to fulfil your elective requirement. This is incorrect. In fact, if you check out the Microsoft Certification Web Page, they even have an example of how you can achieve the MCSD exactly as I’ve described here.
http://microsoft.com/mcp/certstep/mcsdfaq.htm
Clarifying Microsoft’s Certified Solution Developer Certification
Recently I received an email from a reader seeking a clarification on Microsoft’s Certified Solution Developer Certification. In it, she asked if it’s possible to achieve the MCSD by concentrating only on Visual Basic.
If you’re considering getting Microsoft’s Certified Solution Developer Certification, you might be happy to know that it is possible to achieve this certified developer status by concentrating only on Visual Basic.
To become a Microsoft Certified Solution Developer (MCSD), you must pass three core examinations: Desktop Development exam, a Distributed Development exam, and Solution Architecture exam. You must also pass an elective examination.
For the Solution Architecture Examination, you have no choice---you must take the grueling Analyzing Requirements and Defining Solution Architectures (70-100).
Within Desktop and Distributed development, there are a variety of ‘tracks’ that you can pursue: Visual Basic, Visual C++ and Visual Fox Pro. If you intend to pursue the VB ‘track’, you can take the Visual Basic 6 Desktop Examination (70-176) and the Visual Basic 6 Distributed Examination (70-175) to fulfill your three core examination requirements.
As for the elective examination, there are about twenty or so to choose from, including the Visual Basic 5 exam.
Yes, that’s right, Visual Basic 5. Visual Basic 5 is still a supported Microsoft package, and I work with many companies that are still using it. The Developing Applications with Microsoft Visual Basic 5.0 (70-165) examination is available to take as an elective---and if you are like many Visual Basic programmers who have been using it for many years, you may find this examination to be a piece of cake.
Many MCSD candidates are under the mistaken impression that once you have taken two Visual Basic exams you cannot take another Visual Basic exam to fulfil your elective requirement. This is incorrect. In fact, if you check out the Microsoft Certification Web Page, they even have an example of how you can achieve the MCSD exactly as I’ve described here.
http://microsoft.com/mcp/certstep/mcsdfaq.htm
Friday, April 28, 2000
Programming Tips & Tricks #0001---Working with someone else’s code
Tips & Tricks
Working with someone else’s code
The scenario (all too familiar):
You have a new job, and your first programming assignment is to modify a Visual Basic program that was written by another programmer who has left the company. The program is hard to follow. It has no comments, all of the variables are haphazardly named, and all the forms and controls were left with their default names, such as Form1, Form2, Command1, Option1, etc. You’re overwhelmed.
This is not an unusual feeling. In fact, you can feel the same way about your own code a year or so after writing it. So I emphasize these precautionary measures to ensure easy comprehension by others:
1. Option Explicit is coded in all of your modules (this ensures that Visual Basic enforces that all variables are declared before using them)
2. All variables and controls are named using a formal naming convention (i.e. Hungarian Notation)---this makes modifying the program somewhere down the road much easier
3. Code that is repetitive in nature is consolidated into procedures and called from within the program
4. Every module has comments describing its major functions and features
5. Code that is anything out of the ordinary is also commented
Sounds great, but how do these ‘rules’ help you modify someone else’s code? Unfortunately, I’m suggesting you correct the mistakes of the past.
Of course, before you do this, you need to get your supervisor or project leader to ‘buy into’ that plan. Obviously, if he or she is expecting the program modification to be made in about an hour, so taking a week to clean the code and make the modification won’t make you a hit in the Employee cafeteria.
However, I can almost assure you this won’t be the last time this program is modified. Biting the bullet now and cleaning it up will make things much easier on the next junior programmer who finds himself in the uncomfortable position of modifying this code.
Once you have the go-ahead to proceed, the first thing to do is to ensure that Option Explicit is coded in the General Declarations Section of every module in the program. -- if it’s not, add it manually -- and then run the program. Guess what? The program no longer runs. Why?
Coding Option Explicit will cause VB to mark, as a syntax error, every instance of a variable that hasn’t been declared---potentially lethal errors in a program. At this point, you need to identify the variables that haven’t been declared, and explicitly declare them, with a defined type (i.e. Integer, String, Date). While you’re at it, this wouldn’t be a bad time to rename variables using either Hungarian Naming Convention, or a naming convention in use at your company. Using Visual Basic’s Search and Replace features can make this task a lot easier than it sounds.
With all of the variables properly declared and named properly, now is a good time to name those forms and controls in a meaningful way. Keep in mind that when you change the name of a control, the code associated with it can appear to be ‘lost,’ finding its way into the General Declarations Section. To avoid this, first rename any event procedures associated with the control manually with the new name of the control—then bring up the Properties Window for the control and change its Name property there.
At this point, make sure the program runs okay. You’ll find you now have an understanding of how the program works -- so much so, that you should be able to identify code that can be centralized in a subprocedure or function. Along the way, insert comments in your code explaining what’s going on. Write those custom procedures and place them in either a Form Module or a Standard Module (every Visual Basic program I write has one).
Now, with the Visual Basic program nicely sanitized, it’s time to code that simple modification you’ve been asked to make. Hopefully it will be a piece of cake.
Working with someone else’s code
The scenario (all too familiar):
You have a new job, and your first programming assignment is to modify a Visual Basic program that was written by another programmer who has left the company. The program is hard to follow. It has no comments, all of the variables are haphazardly named, and all the forms and controls were left with their default names, such as Form1, Form2, Command1, Option1, etc. You’re overwhelmed.
This is not an unusual feeling. In fact, you can feel the same way about your own code a year or so after writing it. So I emphasize these precautionary measures to ensure easy comprehension by others:
1. Option Explicit is coded in all of your modules (this ensures that Visual Basic enforces that all variables are declared before using them)
2. All variables and controls are named using a formal naming convention (i.e. Hungarian Notation)---this makes modifying the program somewhere down the road much easier
3. Code that is repetitive in nature is consolidated into procedures and called from within the program
4. Every module has comments describing its major functions and features
5. Code that is anything out of the ordinary is also commented
Sounds great, but how do these ‘rules’ help you modify someone else’s code? Unfortunately, I’m suggesting you correct the mistakes of the past.
Of course, before you do this, you need to get your supervisor or project leader to ‘buy into’ that plan. Obviously, if he or she is expecting the program modification to be made in about an hour, so taking a week to clean the code and make the modification won’t make you a hit in the Employee cafeteria.
However, I can almost assure you this won’t be the last time this program is modified. Biting the bullet now and cleaning it up will make things much easier on the next junior programmer who finds himself in the uncomfortable position of modifying this code.
Once you have the go-ahead to proceed, the first thing to do is to ensure that Option Explicit is coded in the General Declarations Section of every module in the program. -- if it’s not, add it manually -- and then run the program. Guess what? The program no longer runs. Why?
Coding Option Explicit will cause VB to mark, as a syntax error, every instance of a variable that hasn’t been declared---potentially lethal errors in a program. At this point, you need to identify the variables that haven’t been declared, and explicitly declare them, with a defined type (i.e. Integer, String, Date). While you’re at it, this wouldn’t be a bad time to rename variables using either Hungarian Naming Convention, or a naming convention in use at your company. Using Visual Basic’s Search and Replace features can make this task a lot easier than it sounds.
With all of the variables properly declared and named properly, now is a good time to name those forms and controls in a meaningful way. Keep in mind that when you change the name of a control, the code associated with it can appear to be ‘lost,’ finding its way into the General Declarations Section. To avoid this, first rename any event procedures associated with the control manually with the new name of the control—then bring up the Properties Window for the control and change its Name property there.
At this point, make sure the program runs okay. You’ll find you now have an understanding of how the program works -- so much so, that you should be able to identify code that can be centralized in a subprocedure or function. Along the way, insert comments in your code explaining what’s going on. Write those custom procedures and place them in either a Form Module or a Standard Module (every Visual Basic program I write has one).
Now, with the Visual Basic program nicely sanitized, it’s time to code that simple modification you’ve been asked to make. Hopefully it will be a piece of cake.
Saturday, March 4, 2000
Fan Mail---March 4, 2000
Just received a very nice piece of fan mail about my books in which the author describes the 'novel' approach of my book
I would just like to say that I enjoy your books on Visual Basic. I have two and am going to buy another soon.
These are the first programming books that I have ever read that aren't extremely boring.
The book is more like an interesting novel because of the way you do the dialogue instead of just spitting out pages and pages of boring, hard-to-follow facts.
I bought the first book in the series about beginning Visual Basic so that I could learn Visual Basic and get a summer job doing programming. I am not even done with the first book, but I still bought the book on objects in Visual Basic.
I used to program in Q-Basic back in the ancient days of un-user-friendly DOS and a year ago, I made an attempt at learning Visual C++, but I now know more in Visual Basic than in both Q-Basic andVisual C++.
Thanks!
Danny
I would just like to say that I enjoy your books on Visual Basic. I have two and am going to buy another soon.
These are the first programming books that I have ever read that aren't extremely boring.
The book is more like an interesting novel because of the way you do the dialogue instead of just spitting out pages and pages of boring, hard-to-follow facts.
I bought the first book in the series about beginning Visual Basic so that I could learn Visual Basic and get a summer job doing programming. I am not even done with the first book, but I still bought the book on objects in Visual Basic.
I used to program in Q-Basic back in the ancient days of un-user-friendly DOS and a year ago, I made an attempt at learning Visual C++, but I now know more in Visual Basic than in both Q-Basic andVisual C++.
Thanks!
Danny
Subscribe to:
Posts (Atom)