Validate and Focus problem

[bbuk]

Hi

I hope someone here can help with this problem.

I have two text boxes, one for part number one for qty. If the user enters a qty and presses enter it is stored and focus moves to the other box.

I use the validate event of the qty box so that if the user enters a qty but does not press enter this is trapped.

What I have a problem with is if the user uses the mouse to click the part number box without first pressing enter to store the qty. A message box is triggered by the validate event of the qty box and the user can either store, return or cancel. So far so good but if the user choosed store the value is stored by a function and the focus should switch to the text box he has just clicked ready to input the next part number.

What actually happens is that the cursor appears in the text box but the mouse pointer stays as an I-beam anywhere on the form and dragging over the text in text2 will select it. I have to click again to be able to enter text with the keyboard.

Sorry for the rambleing description but if anyone can make sense of this and explain the behaviour I would be very grateful.

TIA

Andy

 

[tedsmith]

The following only lets the focus leave a text box if the entry key is pressed.
If you try to get away from it with the mouse, it warns you and all you have to do is press enter.
Uses any number of Indexed Text boxes textNew(0) is quantity
textNew(1) is Part Number etc.
You can easily change the backcolor of the box with the focus to yellow to indicate better which box you will be typing in.

You can make the last text box look like a next page button instead of a command button.

'Set the original backcolor of TextNew(0) = Yellow

Dim BoxChanged(20) As Integer
Dim ActiveBox As Integer
Const NumberOfBoxes As Integer = 2

Private Sub TextNew_KeyDown(Index As Integer, KeyCode As Integer, Shift As Integer)
Dim a As Integer
ActiveBox = Index
If KeyCode = 13 Then 'Enter key
    ActiveBox = ActiveBox + 1
    If ActiveBox = NumberOfBoxes Then ActiveBox = 0
    TextNew(ActiveBox).SetFocus
    For a = 0 To NumberOfBoxes - 1
        TextNew(a).BackColor = vbWhite
    Next
    TextNew(ActiveBox).BackColor = vbYellow
    TextNew(ActiveBox).SelLength = 100 'or maximum likely length
    Select Case Index 'Handle each button's finished data here - verify inputs etc
        Case 0
        'Quantity
    
        Case 1
        'Part No' Insert suggested description in TextNew(2)
        
        Case 2
        'Description (from a lookup snapshot recordset)
            
        Case 3
        'price etc etc
        
        Case 4
        'Next page
        
    End Select
    'update database here
End If
End Sub

Private Sub TextNew_MouseDown(Index As Integer, Button As Integer, Shift As Integer, X As Single, Y As Single)
If Index <> ActiveBox Then
    MsgBox " Press the Enter key to save the previous entry", vbExclamation, "Previous Entry not saved"
    TextNew(ActiveBox).SetFocus
End If
End Sub

Private Sub TextNew_Change(Index As Integer)
If Index = 4 Then TextNew(4).Text = "Next Page" ''Last button - keeps it saying this
End Sub

RE <If you let your programming style be affected by users with limited computer experience you are ultimately not doing your users any favors (they will stay inexperienced)

Just because someone designed a 'standard' GUI I would strongly disagree that it should be persevered with at all costs.

If people had followed this rule centuries ago we'd still be believing the earth was flat and using valves in our mobile cell phones.

 

[strongm]

>it should be persevered with at all costs

I don't think anyone has suggested that,

>Just because someone designed a 'standard'

Some standards are a good idea, which is why, once we have learned to drive, we can jump into most cars and drive them. But that doesn't stop there being a huge range of different cars with different features and doesn't stop car technology moving on (although we might not always know which button switches on the aircon)

And when I press the Q key on a QWERTY keyboard I expect to see the letter Q appear on screen. As I would when using an AZERTY or Dvorak keybooard, even though the key is in a different place. I don't expect a random letter to appear, and I don't expect a prompt to appear on screen asking whether I mean an uppercase Q or a lowercase Q since the keyboard provides me with a standard way to avoid such ambiguity.

 

[BobRodes]

Hi bbuk,

This comes from

http://msdn.microsoft.com/en-us/library/ms971323.aspx#atg_keyboardshortcuts_input_focus_location.

The whole article is well worth reading.

Complying with Standard Keyboard Navigation
A good practice for creating a well-designed keyboard interface is to model it after one that is already familiar to the user, and one that is compatible with other commonly used applications and controls. The following section describes standard keyboard navigation practices to keep in mind when designing a keyboard UI.

Navigating in a Logical Order
The order in which a user moves, or navigates, through the elements of a UI must be logical and consistent with the natural language in which the UI is written. In a well-designed UI, the navigation order starts with the most commonly used control and flows in the direction in which the language is read. For example, in a dialog box in a UI written in English, the navigation order moves from left to right and top to bottom.

In Windows applications, users navigate by pressing the TAB key to move the input focus from one UI element to another. They press the SPACEBAR or ENTER key to choose the currently selected active region or to activate a control or command. Pressing the SHIFT+TAB key combination reverses the navigation order, moving the input focus backward through the elements, and pressing the arrow keys moves the input focus in specific directions within a group of elements.

The point I believe that we are trying to make is about the usefulness of standardized interfaces. Suppose you were designing a car, and had a very good reason to put the gas pedal where the brake was and vice versa. It wouldn't be much of a justification to say that all the people that were going to drive the car weren't already drivers, now would it? Furthermore, any advantage that your system had would be outweighed by the fact that everyone who had any idea how to drive a car would have to spend time getting used to learning to drive yours.

A good example of this concept of learning curve overhead is the continued use of the QWERTY keyboard. This keyboard layout was intended to slow down the typist enough to prevent type bars crashing into one another, as they would on early machines when people typed too fast. While plenty of other layouts have been advocated, the requirement to relearn how to type has been insurmountable in terms of getting another more ergonomic layout adopted. (Wikipedia mentions that 70% of English words can be made with the letters "GHIATENSOR", which were the keys on the home row in the so-called "Ideal" layout of the home row on some early typewriters.)

So, this concept of conforming to established wider practices is something most of us support as a general rule. We're not saying one shouldn't ever deviate, what we are saying is that there are efficiencies on many levels that derive from leveraging the trial-and-error knowledge from which these standards evolve, and one should avail oneself of these efficiencies unless one has considerable justification not to do so.

Which leads to these:

1. Would it be more standard to have a 'save' command button so the enter key goes [etc]
It's more standard to have a save command that is separate from navigation.
2. the whole other argument about how much control you allow the user to have [etc]
This argument is neatly handled by advocating conformance to standard UI practices. If the user wants to use the mouse for everything that's what he's doing with all his other applications too. You'd be better off teaching a class in getting around the screen using the keyboard and selling everyone on the time it will save than to use your application as a vehicle to suppress their bad habits.

HTH

Bob

 

[gmmastros]

Thread summary:

1. bbuk asks question on 23 Sep 09
2. Several people attempt to help
3. bbuk finds answer elsewhere and is gracious enough to share the answer. 25 Sep 09 20:01
4. People comment on standard UI issues.
5. bbuk understands arguments but chooses to ignore advice.
6. comments continue....

There appears to be a shortage of questions already. I think this behavior just makes it worse.

-George

"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom

 

[BobRodes]

<bbuk understands arguments but chooses to ignore advice.

Not sure I agree with you there, george. I don't think he does understand the arguments, which is why I thought I'd try and explain them in some detail.

 

[strongm]

This isn't a just a free tech support site

professionals of all types can participate in discussions with others in their specific areas of expertise

In this case a question has triggered a related discussion about an important element of program design.

One other nice thing about the tipmaster sites, and one of the reasons I like them in preference to sites like ExpertsExchange, is that no one person, not even the original poster, is the final arbiter of when a thread is closed (although obviously they can decide if their question has been answered to their satisfaction).

 

[gmmastros]

Take a look at the defensive comments made by bbuk:

I think it is a bit harsh criticising the interface

I don't understand what is non-intuitive

And that's what I meant when I said you don't understand
the context.

I think on this occassion we will have to agree to disagree.

You say I am deviating from existing UI standards but

Maybe I'm not wrong just different

I'm not saying that discussions are bad. Far from it. I also think it's important to mention issues not directly related to the original question. In this case, standard UI design should have been mentioned. My point is.... enough already.

To me, this feels like a bunch of bullies on a playground picking on the short fat kid. Of course, this is just my opinion. If you want to continue belittling bbuk's interface, I can't stop you.

-George

"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom

 

[bbuk]

Thanks George for casting me as the short fat kid, although the tall fat middle aged man would have been closer to the truth

I'm with strongm regarding the usefulness of this site. I often browse through the posts even if I haven't got a specific question and generally read the one which have a large number of replies. Often these are interesting discussions like this which build on the original question - although often the OP is not participating in the later posts.

Thanks for the link Bob. I have read the article and can see how it is applied in most mainstream programs. I did find one point which supports what I am doing however:

Change to validating fields when the user selects OK or an equivalent command that submits the changes. In this case, you must allow the user to cancel the operation or choose a command to restore default values.

which is what I was trying to achieve in the original question. A class in the use of the keyboard would be an answer but I can’t see management supporting it!

Thanks for the code snippet TedSmith, I think that it gets around the need to use the validate event but I don't think it is significantly different to what I was doing in terms of complying with standards.

HughLerwill, I do have a prompt under the entry box which changes from "Enter Part Number" to "Press enter to input Qty" as soon as a enough of the number is entered to identify a unique part. Maybe this prompt should have said ‘press tab to move’ but that doesn't help my users who don't know what the tab button is.

Thanks to all for the input, I will certainly think more about the keyboard interface on my next app. - but I can’t promise that I will be sticking to the standards!

 

[strongm]

>I don't think it is significantly different to what I was doing

It isn't

>but I can't promise that I will be sticking to the standards!

Which is fair enough.

 

[tedsmith]

Actually my code was specifically designed to NOT use the Tab Key as you originally requested.

I did a short survey and found that no one I know uses the Tab Key for navigating.
They all expect focus to move when they press Enter and if it doesn't they always use the mouse this slowing down entry a lot.

You could easily design it so that focus changes with either Enter or Tab so "experienced" users could also use it without dismay.

Some of my friends who are Internet only users were unaware that any keys will move to the next entry box.

Re car standards, last week I hired an English made car and when I activated the trafficator (turning lights) the windscreen washer came on instead - Grrr!

 

[bbuk]

>Actually my code was specifically designed to NOT use the Tab Key as you originally requested.

I wasn't trying to avoid using the tab key, I just want to include enter as an alternative way to change boxes. In my approach the tab key retains its default function as I don't trap it.

>I did a short survey and found that no one I know uses the Tab Key for navigating.

I'm glad its not only my users that are in some way deviant!

>Re car standards, last week I hired an English made car and when I activated the trafficator (turning lights) the windscreen washer came on instead - Grrr!

At least in the UK we have cars with the steering wheel on the correct side - it's just that the rest of the world choose to deviate from our standard.

 

[gmmastros]

> it's just that the rest of the world choose to deviate from our standard.



-George

"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom

 

[strongm]

>They all expect focus to move when they press Enter

They'll be disappointed when they get a system dialog such as a VB messagebox, then ...

>You could easily design it so that focus changes with either Enter or Tab

Er .. that's basically exactly what Windows will do already, if there isn't a default command button.

 

[tedsmith]

Here in Australia we have imported cars from many countries but all with the steering wheels on the correct side as in UK. It is against the law to import a car with right hand drive.
Most Trafficators are on the right but unfortunately some English and Italian cars have it on the wrong left side.
They switch wheels but don't switch the controls to suit.

>You could easily design it so that focus changes with either Enter or Tab
What I meant was my code snippet could be modified to do this.
Interesting that Keydown or Keypress do not trap the Tab key, but Validate does so you would have to use this as well if you want something to happen after each entry is complete and you press the Tab key.