Programming Tips & Tricks #0008
Visual Basic Command Line Arguments
I recently received an email from a reader who wanted to know if its possible to run a Visual Basic executable program with command line arguments. The answer is yes, although this feature is not as robust as it is with executables compiled with other languages such as C.
What's a command line argument, you might ask?
Let me give you an example. Suppose you want to execute a program whose main form obtains its caption from an argument supplied by the user when the program is executed.
You can take advantage of Visual Basic's Command function, which returns a value equal to the argument supplied after the name of the Visual Basic executable. For instance, if the name of your executable is Test.exe, if you type this value into the Windows Start-Run dialog
Test.exe VB
and enter this code into the Load Event Procedure of the Startup Form
Private Sub Form_Load()
If Command <> "" Then
Form1.Caption = Command
End If
End Sub
when your form appears, "VB" will appear in the form's caption. Notice that we first check to see if the return value of the Command function is equal to an empty string, which will be the case if the user executes your program with no arguments.
Invariably, the next question that is asked is whether you can supply more than one argument to the executable. Other languages, such as C, populate multiple command line arguments separated by spaces into an argument array that is available to the program when it executes.
In Visual Basic, however, everything that appears after the name of the executable is considered a single string argument. Separating multiple arguments with commas, quotation marks, or other delimiters won't affect that--everything after the executable name is considered a single string argument and is returned as a single string from the Command Function.
For instance, typing this statement into the Start-Run Dialog Box
Test.exe I,love,VB
results in the form's caption being set to "I,love,VB".
However, with a little imagination and some string manipulation, it isn't difficult to come up with a workaround to this restriction.
Monday, July 31, 2000
Developer Career Tip #0008---How to get that elusive first programming job with no experience
Developer Career Tips #0008
How to get that elusive first programming job with no experience
I'm forever being asked by my Visual Basic students how to obtain a Visual Basic programming position in today's job market, when you have no 'paid' Visual Basic experience.
I still insist that there are three sure-fire ways to obtain a Visual Basic programming position (at least a junior level position).
The first is to write a fantastic application based on something you know, and showcase that program at your interview. I had a student in a class a few semesters ago who showed me a Visual Basic program he wrote to keep track of the golf handicaps in his weekend golf league. The program was fabulous, and not only did he land a job with it, he's made quite a bit of money marketing it to other golf leagues in our area.
A second way is to volunteer your programming services---choose a charitable or non-profit organization who may be interested in your free services in exchange for the experience it can bring. Several of my students have written programs for their churches---another wrote a program for a local soup kitchen. You'd be amazed at how demanding a 'real' client can be, even one who ultimately isn't paying cash for the product. But the experience is unbeatable--and it's perfectly legitimate to include a non-paid job like this on your resume---even better if the customer is well pleased and will provide a great reference to a prospective employer.
The final way is to take and pass one of the Microsoft Visual Basic Certification exams---start with the VB6 Desktop Exam. Those of you who have been following my tips know that I'm a big believer in using the exams as a way to get your foot in the door. Hiring managers continue to tell me that passing the exam is a great way to get noticed and interviewed---even if you have no experience.
How to get that elusive first programming job with no experience
I'm forever being asked by my Visual Basic students how to obtain a Visual Basic programming position in today's job market, when you have no 'paid' Visual Basic experience.
I still insist that there are three sure-fire ways to obtain a Visual Basic programming position (at least a junior level position).
The first is to write a fantastic application based on something you know, and showcase that program at your interview. I had a student in a class a few semesters ago who showed me a Visual Basic program he wrote to keep track of the golf handicaps in his weekend golf league. The program was fabulous, and not only did he land a job with it, he's made quite a bit of money marketing it to other golf leagues in our area.
A second way is to volunteer your programming services---choose a charitable or non-profit organization who may be interested in your free services in exchange for the experience it can bring. Several of my students have written programs for their churches---another wrote a program for a local soup kitchen. You'd be amazed at how demanding a 'real' client can be, even one who ultimately isn't paying cash for the product. But the experience is unbeatable--and it's perfectly legitimate to include a non-paid job like this on your resume---even better if the customer is well pleased and will provide a great reference to a prospective employer.
The final way is to take and pass one of the Microsoft Visual Basic Certification exams---start with the VB6 Desktop Exam. Those of you who have been following my tips know that I'm a big believer in using the exams as a way to get your foot in the door. Hiring managers continue to tell me that passing the exam is a great way to get noticed and interviewed---even if you have no experience.
Monday, July 24, 2000
Programming Tips & Tricks #0007---Global Keyboard Handler in Visual Basic
Tips & Tricks #0007
Global Keyboard Handler in Visual Basic
One of the questions that I am frequently asked is how to implement Keystroke validation in a Visual Basic Textbox. The answer is that you can insert code into the KeyPress Event Procedure of a Textbox--and implement Keystroke validation that way. For instance, this code will ensure that only numbers are entered into a Textbox---it also permits the user to press enter a BackSpace key in case they make a mistake.
Private Sub Text1_KeyPress(KeyAscii As Integer)
If KeyAscii = 8 Then Exit Sub '8 is Backspace
If KeyAscii <> 57 Then 'Range of numeric values
KeyAscii = 0
End If
End Sub
Entering code into the KeyPress Event Procedure of a Textbox is fine for one or two Textboxes---but If you have a large number of Textboxes on your form, this is not an enviable task. In that case, you have two alternatives:
First, you can make each Textbox a member of a Textbox Control Array, in which case each Textbox 'shares' the same KeyPress Event Procedure. Sharing code like that is the chief benefit of a Control Array.
The second alternative is to set up a Form Level or Global Keyboard Handler by telling Visual Basic that you want the Form's KeyPress Event Procedure to be triggered BEFORE the individual Textbox KeyPress Event Procedures.
You do this by setting the KeyPreview Property of the Form to True. This will cause the KeyPress Event Procedure of the Form to be triggered whenever a keystroke is made for any of the Textboxes on the form. What that means is that you can take the code you write for each Textbox KeyPress Event on your form--and place it in just one place---the KeyPress Event Procedure of the Form.
Global Keyboard Handler in Visual Basic
One of the questions that I am frequently asked is how to implement Keystroke validation in a Visual Basic Textbox. The answer is that you can insert code into the KeyPress Event Procedure of a Textbox--and implement Keystroke validation that way. For instance, this code will ensure that only numbers are entered into a Textbox---it also permits the user to press enter a BackSpace key in case they make a mistake.
Private Sub Text1_KeyPress(KeyAscii As Integer)
If KeyAscii = 8 Then Exit Sub '8 is Backspace
If KeyAscii <> 57 Then 'Range of numeric values
KeyAscii = 0
End If
End Sub
Entering code into the KeyPress Event Procedure of a Textbox is fine for one or two Textboxes---but If you have a large number of Textboxes on your form, this is not an enviable task. In that case, you have two alternatives:
First, you can make each Textbox a member of a Textbox Control Array, in which case each Textbox 'shares' the same KeyPress Event Procedure. Sharing code like that is the chief benefit of a Control Array.
The second alternative is to set up a Form Level or Global Keyboard Handler by telling Visual Basic that you want the Form's KeyPress Event Procedure to be triggered BEFORE the individual Textbox KeyPress Event Procedures.
You do this by setting the KeyPreview Property of the Form to True. This will cause the KeyPress Event Procedure of the Form to be triggered whenever a keystroke is made for any of the Textboxes on the form. What that means is that you can take the code you write for each Textbox KeyPress Event on your form--and place it in just one place---the KeyPress Event Procedure of the Form.
Monday, July 17, 2000
Developer Career Tip #0007---Interview the Interviewer
Developer Career Tips #0007
Interview the Interviewer
In my last article, I talked about the importance of asking a question (or more) during a job interview to let the interviewer know that you are capable of more than just answering questions and that you have a genuine interest in the company.
Don't allow the interview to become a one-way piece of communication where the interviewer learns everything necessary to make a decision as to whether or not you are what the company needs and wants, but you learn nothing about the company to make the same decision. Too many job candidates find themselves interviewing for a programming position, receiving an offer and then finding themselves in a position they don't like.
How can you avoid this?
Be prepared to get the answers to the questions you'll have the first day or first week of your new job---you don't want to wait until then to find out.
I'm not talking about fundamental questions such as salary, work hours, vacation time and other benefits---these are likely to be part of a standard package provided to you prior to the interview.
I'm talking about questions such as:
What type of work will I be doing?
Will I be programming?
If so, will it be new development, or maintenance of existing code?
If code maintenance, is the original author still with the company?
What language or languages will I be writing?
Will I be working as part of a team?
If so, what are the skill levels of my team members?
How many years with the company do my team members have?
Who will be my supervisor?
How many years with the company does he or she have?
While these are questions to which you can easily obtain answers on your first day on the job, by then it may be too late--particularly if you've left a previous position to obtain that long awaited developer's job, only to find out you'll be manning a Help Desk for the next 6 months until the company signs a big contract.
Of course, you may not be in a position to be picky---if you are a candidate just trying to get your foot in the door, any job offer may be a good one.
Next time: An innovative approach to getting your foot in the door
Interview the Interviewer
In my last article, I talked about the importance of asking a question (or more) during a job interview to let the interviewer know that you are capable of more than just answering questions and that you have a genuine interest in the company.
Don't allow the interview to become a one-way piece of communication where the interviewer learns everything necessary to make a decision as to whether or not you are what the company needs and wants, but you learn nothing about the company to make the same decision. Too many job candidates find themselves interviewing for a programming position, receiving an offer and then finding themselves in a position they don't like.
How can you avoid this?
Be prepared to get the answers to the questions you'll have the first day or first week of your new job---you don't want to wait until then to find out.
I'm not talking about fundamental questions such as salary, work hours, vacation time and other benefits---these are likely to be part of a standard package provided to you prior to the interview.
I'm talking about questions such as:
What type of work will I be doing?
Will I be programming?
If so, will it be new development, or maintenance of existing code?
If code maintenance, is the original author still with the company?
What language or languages will I be writing?
Will I be working as part of a team?
If so, what are the skill levels of my team members?
How many years with the company do my team members have?
Who will be my supervisor?
How many years with the company does he or she have?
While these are questions to which you can easily obtain answers on your first day on the job, by then it may be too late--particularly if you've left a previous position to obtain that long awaited developer's job, only to find out you'll be manning a Help Desk for the next 6 months until the company signs a big contract.
Of course, you may not be in a position to be picky---if you are a candidate just trying to get your foot in the door, any job offer may be a good one.
Next time: An innovative approach to getting your foot in the door
Monday, July 10, 2000
Programming Tips & Tricks #0006---Named Visual Basic Arguments
Tips & Tricks #0006
Named Visual Basic Arguments
One of the themes I emphasize in my computer classes over and over again is the importance of writing code that is readable---that is, code that other programmers and developers will be able to understand, and if necessary, easily modify in the future. Some obvious ways to write readable code include the use of program comments in your code---no matter what the language you are using to develop your program, all major languages provide for comments. Something else that can make your Visual Basic more readable is the user of Named Arguments.
Let me illustrate by executing the Visual Basic MsgBox Function to display a Windows Message Box. The Visual Basic MsgBox function has one required argument (Prompt), and four optional arguments (Buttons, Title, HelpFile and Context).
MsgBox “I love Visual Basic”
By default, this code will display a Message Box with a single command button captioned OK, with the text “I love Visual Basic”, and the Visual Basic Project name displayed in the Title Bar of the Message Box.
Suppose I’m not happy with the default Title in the Message Box, and I decide I want to customize it. Doing this is easy—all I need to do is supply the Title argument to the MsgBox function. However, since Title is the third argument, I either need to supply the second argument---Buttons, which is by default presumed to be the value vbOKOnly---or provide a ‘comma placeholder’, like this.
MsgBox “I love Visual Basic”,, “SearchVB.Com”
Notice the two commas back-to-back, with no value in-between. This is the ‘comma placeholder’ and is how we tell VB that although we have a value for the third argument, we have no explicit value for the second argument.
When we execute this code, we’ll see a Message Box that reads “I love Visual Basic”, and that has “SearchVB.Com” for its Title Bar.
Named Arguments can make passing optional arguments easier—and make your code infinitely easier to read and modify. For instance, the code we wrote above can be re-written to this using Named Arguments.
MsgBox Prompt:="I love Visual Basic", Title:="SearchVB.Com"
With Named Arguments, we specify the name of the argument, followed by a colon and equals sign (:=), then the value for the argument. By using Named Arguments, we don’t need to provide a ‘comma placeholder’ for the second argument Buttons. Since we are naming the argument, VB knows that ‘SearchVB.Com’ is the value for the Optional Argument ‘Title’. And since we name the arguments, being able to read and understand the code in the future is much easier.
Named Visual Basic Arguments
One of the themes I emphasize in my computer classes over and over again is the importance of writing code that is readable---that is, code that other programmers and developers will be able to understand, and if necessary, easily modify in the future. Some obvious ways to write readable code include the use of program comments in your code---no matter what the language you are using to develop your program, all major languages provide for comments. Something else that can make your Visual Basic more readable is the user of Named Arguments.
Let me illustrate by executing the Visual Basic MsgBox Function to display a Windows Message Box. The Visual Basic MsgBox function has one required argument (Prompt), and four optional arguments (Buttons, Title, HelpFile and Context).
MsgBox “I love Visual Basic”
By default, this code will display a Message Box with a single command button captioned OK, with the text “I love Visual Basic”, and the Visual Basic Project name displayed in the Title Bar of the Message Box.
Suppose I’m not happy with the default Title in the Message Box, and I decide I want to customize it. Doing this is easy—all I need to do is supply the Title argument to the MsgBox function. However, since Title is the third argument, I either need to supply the second argument---Buttons, which is by default presumed to be the value vbOKOnly---or provide a ‘comma placeholder’, like this.
MsgBox “I love Visual Basic”,, “SearchVB.Com”
Notice the two commas back-to-back, with no value in-between. This is the ‘comma placeholder’ and is how we tell VB that although we have a value for the third argument, we have no explicit value for the second argument.
When we execute this code, we’ll see a Message Box that reads “I love Visual Basic”, and that has “SearchVB.Com” for its Title Bar.
Named Arguments can make passing optional arguments easier—and make your code infinitely easier to read and modify. For instance, the code we wrote above can be re-written to this using Named Arguments.
MsgBox Prompt:="I love Visual Basic", Title:="SearchVB.Com"
With Named Arguments, we specify the name of the argument, followed by a colon and equals sign (:=), then the value for the argument. By using Named Arguments, we don’t need to provide a ‘comma placeholder’ for the second argument Buttons. Since we are naming the argument, VB knows that ‘SearchVB.Com’ is the value for the Optional Argument ‘Title’. And since we name the arguments, being able to read and understand the code in the future is much easier.
Monday, July 3, 2000
Developer Career Tip #0006---Interview Tip #1---Be sure to ask a question!
Developer Career Tips #0006
Interview Tip #1---Be sure to ask a question!
I'm frequently asked, by my readers and students strategies for answering questions during a job interview. There's no doubt that your ability to 'show your stuff' during a job interview is crucial to landing a programming job.
I'll be covering strategies for answering questions in future articles, but today I want to discuss what I think plagues more job candidates than any other single issue--failing to ask a question during the interview.
Not only do I teach and write books, I also own my own consulting firm, and although I do most of my own work, on occasion I do hire someone to help out during busy periods---usually from a pool of candidate students provided to me by my University's Co-Operative Education program.
These students are highly recommended by the Chairman of the Computer Science Department, extremely motivated, and choosing among two or three candidates can be very difficult.
So how do I make my choice?
That's easy---I pick the candidate who asks me the best questions!
Asks questions? Isn't it the interviewer who should be asking the questions, not the job candidate?
Many job seekers are of the mistaken impression that the role of the candidate is to answer questions during the interview. From the interviewer's perspective, however, you can't imagine the poor image that is conveyed of a job candidate who sits through the interview, and politely (and quite skillfully) answers each and every question, and then when asked if they have any questions, simply say 'no' as if they are anxious to leave!
Taking the time to ask a question or two during the interview shows the interviewer that you are enthusiastic and genuinely interested in the position and the company, and that you can not only answer questions posed of you but that you can initiate and carry on a conversation (a skill that is crucial when talking with end users). In short, taking the time to ask a question or two can land you the job!
Another benefit is that it gives you the chance to seek clarification on the job itself, the types of duties that will be required of you, and to learn more about the company and the people with whom you will work. These are questions to which you want answers before you show up for work the first day.
Next time: Questions to ask before saying "Yes, I'll take the job"
Interview Tip #1---Be sure to ask a question!
I'm frequently asked, by my readers and students strategies for answering questions during a job interview. There's no doubt that your ability to 'show your stuff' during a job interview is crucial to landing a programming job.
I'll be covering strategies for answering questions in future articles, but today I want to discuss what I think plagues more job candidates than any other single issue--failing to ask a question during the interview.
Not only do I teach and write books, I also own my own consulting firm, and although I do most of my own work, on occasion I do hire someone to help out during busy periods---usually from a pool of candidate students provided to me by my University's Co-Operative Education program.
These students are highly recommended by the Chairman of the Computer Science Department, extremely motivated, and choosing among two or three candidates can be very difficult.
So how do I make my choice?
That's easy---I pick the candidate who asks me the best questions!
Asks questions? Isn't it the interviewer who should be asking the questions, not the job candidate?
Many job seekers are of the mistaken impression that the role of the candidate is to answer questions during the interview. From the interviewer's perspective, however, you can't imagine the poor image that is conveyed of a job candidate who sits through the interview, and politely (and quite skillfully) answers each and every question, and then when asked if they have any questions, simply say 'no' as if they are anxious to leave!
Taking the time to ask a question or two during the interview shows the interviewer that you are enthusiastic and genuinely interested in the position and the company, and that you can not only answer questions posed of you but that you can initiate and carry on a conversation (a skill that is crucial when talking with end users). In short, taking the time to ask a question or two can land you the job!
Another benefit is that it gives you the chance to seek clarification on the job itself, the types of duties that will be required of you, and to learn more about the company and the people with whom you will work. These are questions to which you want answers before you show up for work the first day.
Next time: Questions to ask before saying "Yes, I'll take the job"
Subscribe to:
Posts (Atom)
