Solved

go to the next control by pressing "ENTER" ?

Posted on 2001-08-31
21
505 Views
Last Modified: 2008-02-07
Hello,

I would like to know hot could I do to make a control (textbox) to be validate by an 'ENTER' and the focus would go to the next (textbox) control.

And more : How can I do : after you have enter the 4 numbers of a control (designed with maxlenght at 4)
it validates immediately and go to the next control automatically.

And can I make entering masks to make easier to enter the controls of a form (ex : put the '/' for the dates, and so on).

Thank you very much.

Laurent Diep.
0
Comment
Question by:laurent_diep
  • 10
  • 4
  • 2
  • +4
21 Comments
 
LVL 8

Accepted Solution

by:
DennisBorg earned 50 total points
ID: 6446094
>And more : How can I do : after you have enter the 4
>numbers of a control (designed with maxlenght at 4)
>it validates immediately and go to the next control
>automatically.

In the textbox's Change event, you could use code such as the following:

   With Text1
      If Len(.Text) = .MaxLength Then
         'You can use one of the following two lines
         'depending upon the approach you want to take
         OtherCtrl.SetFocus
         'SendKeys "{tab}", True
      End If
   End With


-Dennis Borg
0
 

Expert Comment

by:woodsrr
ID: 6446103
If you use and array of text boxes its real easy:

Private Sub Text1_Change(Index As Integer)
    If Len(Text1(Index).Text) = 4 Then
        Text1(Index + 1).SetFocus
    End If
End Sub
0
 
LVL 8

Expert Comment

by:DennisBorg
ID: 6446106
>I would like to know hot could I do to make a control
>(textbox) to be validate by an 'ENTER' and the
>focus would go to the next (textbox) control.

Use the KeyPress event of the textbox. When KeyAscii equals 13, the ENTER key has been pressed.

For example:

Private Sub Text1_KeyPress(KeyAscii As Integer)
   If KeyAscii = vbKeyReturn Then
      KeyAscii = 0 'Suppress the Beep
      Debug.Print "ENTER"
   End If
End Sub


Instead of the Debug.Print statement, you could invoke your validation routine and go to the next control as needed.


-Dennis Borg
0
 
LVL 8

Expert Comment

by:DennisBorg
ID: 6446126
>If you use and array of text boxes its real easy:
>
>Private Sub Text1_Change(Index As Integer)
>   If Len(Text1(Index).Text) = 4 Then
>       Text1(Index + 1).SetFocus
>   End If
>End Sub


Good point, woodsrr!

But if you use this approach, you'd want to make sure you're not on the last element of the control array.

It would also assume that the index values for all elements of the control array are numbered consecutively. Usually this is the case, but I've seen a few cases where they weren't consecutively numbered.

Here is a revision of the above code which would take into account the possibility of being on the last element of the control array.

It does make the assumption that if you are on the last one, you'd then want to go back to the first. If this is not desired, then you can reprogram its behavior:



Private Sub Text1_Change(Index As Integer)
   With Text1
      If Len(.Item(Index).Text) = .Item(Index).MaxLength Then
         If Index < .UBound Then
            .Item(Index + 1).SetFocus
         Else
            .Item(.LBound).SetFocus
         End If
      End If
   End With
End Sub


-Dennis Borg
0
 
LVL 22

Expert Comment

by:rspahitz
ID: 6446260
This is actually a very complicated question.

It appears that you are trying to make a windows form act like a DOS form.  In those days, things worked differently, where the fields were completed with the enter key, and there was the auto-jump feature where when the user typed past the end of a field it jumped to the next.

The reason it is complicated is because:
1) Many users will expect tab to jump between fields and others will expect enter. (Either should work based on the previous comments offered.)
2) If there is a "default" button on the form, the enter key will activate that button instead of going to the next field.
3) When the user clicks back on the field for futher editing, the cursor will likely be at the end of the field instead of the beginning (which could be fixed in gotfocus)
4) The user obviously cannot "cursor around" the way you could in a DOS window.
5) If some fields are auto-jump and others require the enter key, users can get confused.


Basically, a Windows form is not a DOS form, and you're probably better off training your users to deal with it than trying to program something that is subject to lots of related problems...and you're users will be better off as they can then use the many other apps available in Windows.
0
 
LVL 8

Expert Comment

by:DennisBorg
ID: 6446571
rspahitz:

I disagree with the thought that having the Enter key equates to DOSifying an application. There have been many Windows-based applications that allow both the Tab key *and* the Enter key to cycle thru the fields on a form.

The Enter key triggering the Default Button is used in the context of a Dialog Window, and should not be used in normal run-of-the-mill data entry screens. This (about Dialog Windows and Default Buttons) has been the standard and expected behavior of Windows applications since Win 3.x, if not earlier.

Neither is the AutoTab feature a DOS-only type of feature. AutoTab means automatically going to the next field once the input mask for the given field has been completed; like when you've typed in the whole phone number.

The AutoTab feature can save a data-entry person a lot of work, because you can save them keystrokes, since they do not have to hit Tab/Enter after filling in a Social Security Number, a phone number, a two-letter state abrevation, etc.  And this can be very nice for those who input hundreds, upon hundreds and thousands of records in a day's time.

Microsoft Access, which, as we all know, *is* a Windows program, allows both the Enter Key to cycle thru the fields on a form, and it also supports the AutoTab property for certain controls such as the TextBox control.


It is not good to throw away a good idea or good features just because it happened to be used in DOS.

That's sort of like saying that we're MACifying the PC's by using Windows. Of course, Icons did not originate with MACs; I believe Macintosh got that idea from Xerox.



>3) When the user clicks back on the field for futher
>editing, the cursor will likely be at the end of
>the field instead of the beginning (which could be fixed
>in gotfocus)

I honestly don't know what you're trying to say here.


-Dennis Borg
0
 
LVL 8

Expert Comment

by:DennisBorg
ID: 6446612
>Basically, a Windows form is not a DOS form, and you're
>probably better off training your users to deal with it
>than trying to program something that is subject to lots
>of related problems...and you're users will be better off
>as they can then use the many other apps available in
>Windows.

With all due respect, telling (or training) your users to "deal with it" is not going to win you a lot of business. They'll start buying your competitor's programs who does give them the features they need/want; meanwhile they'll be throwing your program into the trash.

And in a job environment, this can cause you to alienate your end-users who will believe that you don't care about making the program easier for them to use and work with on a day-to-day basis; and they may speak to your supervisor about it if they feel that you are not giving them what they need.

I'm sure that you didn't mean it this way, rspahitz. But it's something that developers need to think about.


-Dennis Borg
0
 
LVL 22

Expert Comment

by:rspahitz
ID: 6446662
Dennis, let me address your concerns...

In the "old" (DOS) days, the tab key was never used to switch between fields.  Microsoft apparently thrust that upon us with Windows, and users were forced to deal with it.  Eventually users came to use it as the acceptable way to navigate through controls in Windows.

I still feel that any application that uses the enter key for navigation is either looking at it from the perspective of DOS-style data-entry, or (in the case of databases) record-style data-entry.  There are certainly times that it is appropriate, but usually in Windows the enter key means you're done with the record which roughly equates to a Window of information.  As such, I believe, Microsoft adapted the tab key to navigate between fields within a record/window.

--
True, a "default" button should not normally be used outside of a dialog window, but in the case of a record, as described above, I think it is very appropriate to use the enter key to indicate that you're done with the record and ready for a new one...how else should the data-entry people proceed to the next record?  Certainly not with the mouse, which takes them away from the keyboard and wastes time switching modes.  Probably not with a key combination (Ctrl-N?) which requires multiple keypresses.  Maybe with a function key, but that just seems so passe' ("F1=help, F2=save, F3=new, F4=...")

--
I agree that auto-tab can be useful for data-entry clerks who fill in whole fields, but it can be very confusing when used incorrectly.  If you have auto-tab on, for example, a dollar field, there's a good chance that the user will get auto-tab sometimes and require a tab/enter other times.  This is really bad design since if the user slips and tabs immediately after an auto-tab, everything goes out of synch.

The auto-tab feature can be equated to an auto-space feature for a tech writer.  Every time a period is entered, auto-space twice so the writer doesn't have to type as many keystrokes. (Actually the new standard is one space after a period.)  Helpful?  Yes.  Dangerous? Potentially because this is not necessarily standard behaviour in all places.

Again, it's a good feature if implemented correctly, but extermely bad if done wrong.  I personally think it's not usually worth the risk.
--

My 3rd comment was that as you type in a textbox, the cursor stays where you last left it.  If you tab back to the field (not click as I indicated), the cursor will be at the end unless you program it otherwise.  MS Access addresses this by always highlighting the field when you come into it--sometimes a good feature, sometimes annoying.  As such, this should also be programmed with care.

--
--
So all in all, I think each of the features has its place, but its use should be based partly on how well it allows the user to perform in an efficient manner, and partly on how well it prevents the user from screwing up.
0
 
LVL 22

Expert Comment

by:rspahitz
ID: 6446676
Dennis, regarding the "deal with it" issue, I totally agree with you.  If you "force" your users to deal with your company's decisions, you had better have the market-share of Microsoft to be able to force it down people's throats!!!

I tried to be careful about that one.  My intent was that if you train the users on following industry standards (rather than the way they're used to doing things) both sides win.

That said, there are some things better left alone, which may mean that you have to write code to accomodate the new technology using the old standards.

Either way, again, it should be a strategic decision to do this rather than an arbitrary decision based on what some corporate head requested without thinking.

After all, the first computers were very expensive, took lots of space, and were about the same speed as a human when it came to calculating.  If some people didn't have a vision of their potential, computers would not exist today, there would be no Internet, satellites, etc--all of the things we take for granted today.

Somewhere you have to draw the line, and if you can properly market it to your customers, everyone can win.
0
 
LVL 8

Expert Comment

by:glass_cookie
ID: 6447123
Hi!

This is how I'll approach the situation:

Private Sub Text1_Change()
If Len(Text1.Text) = 3 Then
'Send focus to next control if length=maxlength (ie.3)
SendKeys "{TAB}"
End If
End Sub

Private Sub Text1_KeyDown(KeyCode As Integer, Shift As Integer)
Select Case KeyCode
'For shifting focus to the next control
Case vbKeyReturn
SendKeys "{TAB}"
End Select
End Sub

'For entry of date
Private Sub Text2_Change()
'For adding "/" after the days and months
If Len(Text2.Text) = 2 Then
Text2.Text = Text2.Text + "/"
SendKeys "{END}"
ElseIf Len(Text2.Text) = 5 Then
Text2.Text = Text2.Text + "/"
SendKeys "{END}"
End If
End Sub

That's it!

glass cookie : )

PS. I'm sorry if this is a duplicate of any expert's comment - not much time to read everything.
0
Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

 

Author Comment

by:laurent_diep
ID: 6447393
DennisBorg,
woodsrr,
rspahitz,
glass_cookie

Thank you all of you,

I think I have the answers now.

I would like to split the points between four of you :
I will ask the community

Thank you again.

Laurent Diep.
0
 
LVL 15

Expert Comment

by:ameba
ID: 6447423
I would try to convince customers that using "Tab" gives better productivity and it is 'Windows standard':

- data entry must be done using both hands (try pressing Tab with the right hand, you'll see it doesn't work nice)
    - forcing  both hands  gives:
      a)  more keys can be typed
      b)  forces better bussines organization (you must use a 'document holder', since left hand must be free for typing)

- allows using "Enter" to finish editing quickly (e.g. when Save is Default button) - this is better than walking all fields until you reach Save button.


I used 'Immediate completion' for entering school grades - it allows fast data entry, and I noticed SendKeys "{Tab}" was a bit slow (e.g. 15 grades can be entered in less than a second, if all grades are the same).  Next time I'll use 'OtherCtrl.SetFocus'.
0
 
LVL 1

Expert Comment

by:Computer101
ID: 6447610
Points reduced to 50 to allow point split.

Thank you
Computer101
Community Support Moderator
0
 

Author Comment

by:laurent_diep
ID: 6451278
Thank you very much.

Laurent Diep.
0
 
LVL 8

Expert Comment

by:DennisBorg
ID: 6453763
rspahitz:

>In the "old" (DOS) days, the tab key was never used to
>switch between fields.

It almost sounds as if you think I am not familiar with those days. :-)

But you would be incorrect to assume that the tab key was never used to switch between fields in any DOS programs.



>but in the case of a record, as described above, I think
>it is very appropriate to use the enter key to indicate
>that you're done with the record and ready for a new one

I could appreciate that "definition" of the behavior of the Enter key. However, this would be changing the existing industry standard; something you strongly suggest we do not do.

In most Win Apps today, what does the Enter key do when the focus is on a text box?  Nothing, except perhaps to cause a beep to be emitted from the PC speaker. And of course, if you are working with a dialog box, then the Enter key would trigger the default button.

But outside that context (dialog boxes), in the normal context of most normal Win Apps, the Enter key does nothing.



>how else should the data-entry people proceed to the
next record?

This depends upon the make up of the screen. Are you looking at a screen showing a single record? Or are you looking at a grid of records?

Typically, when you move off of the last record as if you're going to the next record, gives you the ability to add a new record.

In addition to that, the user can use the mouse to click on a button or a menu item. If the program is well-written, there will also be a keystroke they can hit to do the same.



>Certainly not with the mouse, which takes them away from
>the keyboard and wastes time switching modes.  Probably
>not with a key combination (Ctrl-N?) which requires
>multiple keypresses. Maybe with a function key, but that
>just seems so passe' ("F1=help, F2=save, F3=new, F4=...")

Contrary to your suggestion here, a well written program should support mouse-users and keyboard users. Your end-users will be of varied expertise; some beginners, others being more advanced users.



>I agree that auto-tab can be useful for data-entry clerks
>who fill in whole fields, but it can be very confusing
>when used incorrectly.

Most *anything* can be quite confusing if it is used incorrectly. Just think of some young person who is learning how to drive a car. They try to turn on the wipers and get the Hi/Low headlight beams instead. Bad design? Not necessarily. More likely, it's simply the fact that the person is learning how to use a new tool and has not completed training yet.

You cannot write a program without it being used incorrectly by someone; unless you have a "Hello World" type of application.


>If you have auto-tab on, for example, a dollar field,
>there's a good chance that the user will get auto-tab
>sometimes and require a tab/enter other times.

First of all, if a particular field is configured as an auto-tab field, it will *always* be auto-tab. It would not auto-tab sometimes and not auto-tab other times.

Secondly, a Dollar Field is *NOT* really a good candidate for the AutoTab feature. AutoTabs are used on fields which *always* require a fixed number of characters inputted. For example, a Social Security Number, a Tax ID, a Phone Number, etc.



>This is really bad design since if the user slips and
>tabs immediately after an auto-tab, everything goes out
>of synch.

Bad design because a Dollar Field was configured as AutoTab, not because of some user's inexperience with the program or with computers in general.



>The auto-tab feature can be equated to an auto-space
>feature for a tech writer.  Every time a period is
>entered, auto-space twice so the writer doesn't have to
>type as many keystrokes.

Not really the same thing at all; kind of similar, but they cannot be equated whatsoever.

The period can be used in acronyms, which means you do not want *any* spaces after that period. If it is configured to produce two spaces after the period, then certain abreviations would be affected. For example: Mr. Smith  You would want only one space after the period, not two.

So you can see that the circumstances for the AutoSpacing is subjective; sometimes you want it, other times you don't.

However, for AutoTabs, it is quite different. A Social Security Number will *always* have 9 characters. If you have entered less than 9 characters, you have not completed the field. If you have entered exactly 9 characters, then you *have* completed the field. That is very clear-cut.



rspahitz, you seem to think it a requirement to write one-size fits all programs.

My belief is not that narrowly focussed. I believe is that a well written program will accomodate users of all levels, as much as it can. It should have both excellent mouse *and* keyboard support. The AutoTab feature should be able to be turned on/off by the user. There should be sufficient training in place, regardless of how dogmattically you feel you adhere to industry standards. And so on.


You seem to argue that using the Enter key to navigate to the next field would confuse users. I don't see how. The Enter key, which by industry standard does nothing (except in Dialog Boxes) would now serve a function, without prohibitting the use of the Tab key.

So Tab-users still use the Tab key with absolutely no problems. Likewise, the Enter-users also experience no problems navigating from one field to the other.


rspahitz, my whole point initially was that your proposal of throwing a feature out simply because that feature was used in DOS programs is a bad proposal.

For if we flatly refuse to use features in our programs on the sole basis that it was used in a DOS program, then you would also have to stop using Text Boxes (i.e. Edit Fields), you would have to prevent users from using the Mouse, you could not use any Buttons in your programs, etc. For all of these features have been in DOS programs prior to Windows' existance.

-Dennis Borg
0
 
LVL 8

Expert Comment

by:DennisBorg
ID: 6453764
rspahitz:

>If you "force" your users to deal with your company's
>decisions, you had better have the market-share of
>Microsoft to be able to force it down people's throats!!!

So your suggestion is to go contrary to your company's decisions and get fired for doing so? That's interesting.

Then your company would hire someone else to do your job who will do it as the company sees fit.

There have been times where I have suggested a better way to the company. Sometimes they see it and go with it; other times they disagree and want you to do it their way anyway.

You work for them, it's your job to do it how they want it done. If you don't, then you don't have a job.



>My intent was that if you train the users on following
>industry standards (rather than the way they're used to
>doing things) both sides win.

One thing you have to realize, rspahitz, is that the Industry Standards, especially in the computer arena, are constantly changing.

There are new controls today that have become standard in application design, which did not exist one or two years ago.

It's not as static as you seem to be suggesting.

On one hand, you say we should adhere dogmatically to industry standards. But on the other hand, you say we should change, as when Microsoft proposed new standards for applications.



>Either way, again, it should be a strategic decision to
>do this rather than an arbitrary decision based
>on what some corporate head requested without thinking.

My point exactly. It should be a strategic decision, rather than arbitrarily based upon some dogma. It should be a stretegic decision, instead of saying, "That is how DOS did it, therefore we will not do it that way."

Some good ideas from yesterday are still good ideas today.

Just remember, DOS also used graphics, mouse pointing devices, Edit Fields, etc. Should we discard these in our programs today, simply because DOS did it that way?


My point is not that using the Enter key for field navigation is a good idea (although I don't think it a bad idea). Rather, my point is simply your reasoning for discarding that idea:

   DOS did it that way, therefore we shall not do it that way.

This is very bad reasoning. Like you said, it should be based upon strategic reasoning, instead of upon arbitrary dogma.



-Dennis Borg
0
 
LVL 8

Expert Comment

by:DennisBorg
ID: 6453790
ameba:

>I would try to convince customers that using "Tab" gives
>better productivity and it is 'Windows standard':

I would suggest that it is not the *standards* which induces better productivity, but rather the reasons for the standards. Which could be the very reason why the standards keep changing ... we find better ways of doing things, so we change the standards.

I do not find hitting Tab instead of hitting Enter to be more productive. Nor do I find it any more productive the other way around. One key does not respond quicker than the other.




>data entry must be done using both hands (try pressing
>Tab with the right hand, you'll see it doesn't work nice)

Just about as easy as hitting the Enter key with your left hand; you'll see that it also doesn't work nicely.

But that hardly proves a point, except that one should learn how to type, and learn which hand and fingers should be used with which keys on the keyboard.


>- allows using "Enter" to finish editing quickly (e.g.
>when Save is Default button) - this is better than
>walking all fields until you reach Save button.

You would be describing a Dialog Box here, as opposed to a "normal" window.

For normal windows, the Enter key does not do anything. It is in dialog boxes for which the Enter key activates a default button. (at least for programs that adhere to industry standards)


-Dennis Borg
0
 
LVL 8

Expert Comment

by:DennisBorg
ID: 6453793
Laurent Diep:

>Thank you very much.

You are very welcome. I'm glad I could help.


Thank-you,

-Dennis Borg

0
 
LVL 22

Expert Comment

by:rspahitz
ID: 6454226
Dennis, as strange as it may seem, I believe that we are thinking on the same lines.

I truly believe that you must give your users what they want, but it is also our responsibility as programmers to show the users and management the best to do something so as to increase productivity.  Sometimes this means bucking the existing rules established within a company (but not usually by risking your job, although I'd hate to work for a company that didn't respect my expertise on I.T. decisions--they may choose to override it, but they should at least listen!)  Sometimes we must accept "bad" standards such as those thrust upon us by Microsoft.  And yet other times we must change our standards to maintain a higher level of productivity.

For example, suppose that your company said that you must support only Win 3.1 machines and that they want an app that will allow their clerks to maximize their data-entry capabilities on those machines?

Would I do it?  Sure!  Would I first argue some points?  Of course:

1) Win 3.1 is not the current standard.  By going full-speed ahead in this route, we will likely hit a dead-end when we want some future 3rd-party features.

2) Win 3.1 has many problems that reduce productivity compared with newer versions, partly because of stability and partly because of non-loner-supported drivers.

3) Newer versions offer more features that may reduce development costs.

etc.

--
By the way, I'm guessing that the reason Microsoft started pushing for the tab-between-fields standard versus enter-key-between-fields was because most people are right-handed and could easily use tab key from their left hand and mouse from right-hand.

If users will rarely touch the mouse, the app should be design with the keyboard as the main focus, and the Enter key could be a major part of that focus.  However, because Windows is a multi-tasking enviroment, users will PROBABLY be using other applications.  By allowing users to follow dual standards (tab/enter), you are potentially opening up a can of worms because then the users may start asking you to implement and "enter key solution" for apps out of your control.  If you tell them you can't you may appear incompetent.

A better solution is to train users to use every app they will likely use, and to try to give them a common interface.  If they will use your "enter-key-based" app 95%, then by all means, give them an isolated, customized solution.  Otherwise, they deserve an app that reduces their learning curve on all apps.

The whole purpose of Windows was to create a common interface.  If you reject this concept, you really shouldn't be developing in the Windows environment (IMHO).  Presonally, I bucked this for a long time because I liked the DOS controls, but eventually realized the benefits of standardization.

0
 
LVL 15

Expert Comment

by:ameba
ID: 6454363
To discuss, or not...
It depends on your role.

Once, I said requirement for my software is Win95, the admin installed Win98 (he 'knew' it was better), and he argued with me, trying to 'convince' me what is better.  Well, he didn't last long.
0
 
LVL 8

Expert Comment

by:DennisBorg
ID: 6455421
>Dennis, as strange as it may seem, I believe that we are thinking on the same lines.

It does look that way .... doesn't it?  :-)


-Dennis Borg
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Introduction In a recent article (http://www.experts-exchange.com/A_7811-A-Better-Concatenate-Function.html) for the Excel community, I showed an improved version of the Excel Concatenate() function.  While writing that article I realized that no o…
You can of course define an array to hold data that is of a particular type like an array of Strings to hold customer names or an array of Doubles to hold customer sales, but what do you do if you want to coordinate that data? This article describes…
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

15 Experts available now in Live!

Get 1:1 Help Now