Accept Enter key from text box

L

laroberts

Freshman
Joined
Jun 29, 2005
Messages
34
On a form of mine I have a textbox in which a user places his password, below this box is a button that says Login. I would like to make it so that the user can just type in their password and either hit that button or just hit enter. How can I make it use the enter key as well from that box?

Also when the form loads... How do I make the cursor default right to inside that textbox so they do not have to click in it before typing?

Thank you!!!!!! :D
 
To make TextBox1 the active control when the form loads add the following snippet in the Form's Load event.
Visual Basic: 
Private Sub Form1_Load(....) Handles MyBase.Load
    Me.ActiveControl = Me.TextBox1
    Me.KeyPreview = True '(see below)
End Sub
To make the Enter key close the form from btnOkay set the form's KeyPreview properity to True or use Me.KeyPreview = True in the form load event.

Then create a form KeyPress event and use:
Visual Basic: 
Private Sub Form1_KeyPress(....) Handles MyBase.KeyPress
    If Asc(e.KeyChar) = Keys.Return Then
        btnOkay.PerformClick()
        e.Handled = True
    End If
End Sub
I hope that helps.
 
This part does not work

Hey thank you for the help. Most of it works however it does not seem to like this line...

btnOkay.PerformClick()

It is complaining about the btnOkay

Any ideas?
 
Forget all that. You make a button the default button of a form by assigning it to the form's AcceptButton property, which you can do in the designer. You then set the Button's DialogResult property to OK and then when the user presses the ENTER key the form will dismiss and return OK. You can also assign a CancelButton, which will be clicked when the user presses the ESC key and the form returns Cancel.
 
True, jmcilhinney, but that use is rather limiting. Using the form's KeyPress, KeyDown or KeyUp property affords unlimited abilities with all controls, menu items, etc. and in my opinion is a much better habit to get into.
 
DiverDan said:
True, jmcilhinney, but that use is rather limiting. Using the form's KeyPress, KeyDown or KeyUp property affords unlimited abilities with all controls, menu items, etc. and in my opinion is a much better habit to get into.
Click to expand...
You are quite correct that handling keyboard events gives more flexibility, but we aren't looking for unlimited abilities here. The question here is how to click the default button when the ENTER key is pressed, and the AcceptButton property was created specifically for this purpose and is the "proper" way to provide this functionality. Why handle events when all you have to do is set one, purpose-built property?
 
As I stated earlier ...and in my opinion is a much better habit to get into.

There is a reason for this. As student and beginner programmers start working on larger and more complicated projects, the habits that were used in the beginning could become very annoying. With large .Net projects the IDE takes quite some time to refresh between Designer and Code modes as it re-writes the .resx files. I'm currently working on a project with close to one million lines of code. The more I put into code and not into the Designer, the quicker the IDE operates and the easier it is to find the subs. Additionally, occasionally the IDE has a "brain fart" and strange things happen in the .resx files. This causes the Designer not to show at all, but rather display a white screen with a Red Critical X. Copying code to a new form is simple, trying to remember all the set properties in the Designer isn't... especially when the form was written 6 months to a year ago or by another programmer that is not longer working at your office. I don't think there are any professional programmers here that would differ from my opinion.

What this boils down to is that , in my opinion, it is better to start learning the right habits from the start.
 
DiverDan said:
As I stated earlier ...and in my opinion is a much better habit to get into.

There is a reason for this. As student and beginner programmers start working on larger and more complicated projects, the habits that were used in the beginning could become very annoying. With large .Net projects the IDE takes quite some time to refresh between Designer and Code modes as it re-writes the .resx files. I'm currently working on a project with close to one million lines of code. The more I put into code and not into the Designer, the quicker the IDE operates and the easier it is to find the subs. Additionally, occasionally the IDE has a "brain fart" and strange things happen in the .resx files. This causes the Designer not to show at all, but rather display a white screen with a Red Critical X. Copying code to a new form is simple, trying to remember all the set properties in the Designer isn't... especially when the form was written 6 months to a year ago or by another programmer that is not longer working at your office. I don't think there are any professional programmers here that would differ from my opinion.

What this boils down to is that , in my opinion, it is better to start learning the right habits from the start.
Click to expand...
Well, in my opinion, you are advocating use of the wrong habit. The AcceptButton property has been specifically created to provide "default button" behaviour. You are proposing using a more general, more complex (albeit not greatly) solution when a simple, specific solution to the problem at hand already exists. How about we don't use the designer at all and do everything in the code window just in case the IDE might have a "brain fart"? This is analogous to what you are suggesting. Using the designer is limiting and vulnerable to IDE bugs, whereas you can do absolutely anything that the language permits in code, so why use the designer at all? We use it because it is a tool that has been created for a purpose and it provides a simpler, more efficient option.
 
An interesting set of postings on differing styles of programming VB.Net.

Speaking to both replies, I would offer the following opinion:
To not use the available tools with a product such as Visual Studios seems to be a self-defeating thought process. To have the tools and not use them would (IMHO) increase the complexity of and time required to complete any project beyond the simplest. Speaking as a VB 'noob', I do appreciate and understand the benefits of being able to understand how and what attributes are used and/or set in the development of a form / class/ object/ etc. I have a greater appreciation for the tools that are part of the Visual Studio IDE. My learning curve has been eased a bit with the availblity of those tools.

Speaking to the comments about the loss of code or attributes or entire forms and not wanting to spend time trying to recreate them; I would offer the following as comments /suggestions. The loss of code/ forms / etc can be a serious blow to any development project. That loss can be lessened by using tools and processes available to almost any IT professional.

One of the more cost effective methods is to use a versioning / central repository style of code / form /etc control. As a programmer, I too find the requirements and inherent restrictions with these products to be a bother yet I have learned to really like and really use those tools. I have used PVCS and M/soft SourceSafe as well as homegrown products. I have even written batch processes to perform some of the basic operations myself in order to provide the rudimentary support that my project required.

Another piece that ties directly in is the creation of documentation for each form/ module/ class/ etc. Yes, I know that documentation is rated right up there with root canals and mother-in-laws as something you wish to do or see. ;) However, good documentation can save a project when a loss of code etc occurs. Documentation can provide a means of recreating a process, a form, a class or whatever was lost in conjunction with repository/ source control software.

The last item to be discussed is in many ways the key to all of this and that is discipline. The discipline to actually create the documentation and use really use the software control product. Any shop can have all types of standards and software to provide this sort of support and information but without discipline, alot of money and time has been and will be wasted.

Just some thoughts :)
 
a million lines of code ? man! that's some complex form.
and either you've been cranking out a thousand lines of code day
for the last three years or you've resorted to 'other methods', best
not described in polite company.
 
Back
Top