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

 

[HarleyQuinn]

Andy,

Could you show us some code to demonstrate the how you've got to this stage?

HarleyQuinn
---------------------------------
Carter, hand me my thinking grenades!

You can hang outside in the sun all day tossing a ball around, or you can sit at your computer and do something that matters. - Eric Cartman

Get the most out of Tek-Tips, read FAQ222-2244: How to get the best answers before post

 

[HughLerwill]

>If the user enters a qty and presses enter it is stored ...

I can't understand why you want to insist that the user press enter to confirm the change. If a qty has been entered it is pretty certain the user wants what he has entered, why not just let focus leave the control after validating that qty entered is an acceptable value.

 

[bbuk]

Hi HughLerwill

Thanks for the reply. It is possible that after entering the part number and the qty the user will notice that the part number is incorrect and will naturally click in the part number box to correct it, therefore I need to confirm if this is the case or if they actually want to store the qty and are just going to the next part number. If they press enter as instructed the qty is automatically saved and the part number box is cleared and gets the focus ready for the next number.

Andy

 

[bbuk]

Hi HarleyQuinn

Thanks for the reply.

This is the validate code:

Private Sub txtNewQty_Validate(keepfocus As Boolean)
Dim ret As VbMsgBoxResult

If Changed_Qty Then
    
    ret = MsgBox("Quantity value has been changed but not stored." & _
        vbCrLf & "Choose 'Yes' to store the new quantity or 'No' to ignore change", vbCritical + vbYesNoCancel, "Record Change?")
    Select Case ret
        Case vbYes
            
            If Not checkqty Then keepfocus = True
            
        Case vbNo
            
            Me.txtNewQty.Text = ""
            Changed_Qty = False
            
        Case vbCancel
        
            keepfocus = True
        
        End Select
        
End If

End Sub

The description gotfocus code:

Private Sub txtPartDesc_GotFocus()

    Me.txtPartDesc.BackColor = vbYellow
    Me.lblTip.Caption = "<< Type a part number >>"

End Sub

The function to check for unlikely qantities (eg part number entered as qty - it happens!)

Public Function checkqty() As Boolean
Dim qty As Double
Dim ret As VbMsgBoxResult
           
            qty = CDbl(frmMain.txtNewQty.Text)
            
            If qty > 100 Then
                ret = MsgBox("Have you really counted " & vbCr & _
                qty & " x " & frmMain.txtPartDesc.Text, vbYesNo + vbQuestion, "Please Confirm Quantity")
                If ret = vbYes Then
                    
                    updateqty qty
                    checkqty = True
                    
                Else
                    
                    checkqty = False
                
                End If
            Else
                
                updateqty qty
                checkqty = True
            
            End If

End Function

The qty box looses focus code:

Private Sub txtNewQty_LostFocus()

    Me.txtNewQty.BackColor = vbButtonFace
    Me.lblTip.Caption = ""

End Sub

I think thats all the code that is involved. Thanks for looking!

Andy

 

[ChewDoggie]

"It is possible that after entering the part number and the qty the user will notice that the part number is incorrect and will naturally click in the part number box to correct it..."

Personally, I'd place part numbers in a dropdown list. It saves on the amount of validation that has to occur and, IMO, makes it easier to do validate with other controls.

Chew

10% of your life is what happens to you. 90% of your life is how you deal with it.

 

[strongm]

There's a part of me reading this that is saying "redesign the interface a bit" ...

 

[bbuk]

There are approx 3860 partnumbers with associated descriptions so a drop down box is not really practical. What I have is a data grid containing all the part numbers and descriptions, then as the user types the number the datagrid is filtered until only one part is left. This is needed becasue not all the parts are labelled and often the counter will know the first part of the number and can deduce the rest from the description eg a red tap might be 931-605-010 and a blue tap 931-605-019. So long as you know the 931-605 (common for all taps) you can use the description to find the correct number. Once the list is down to one number the user can press enter and the focus to the qty box and the user types the qty, then presses enter the cut is saved, the focus moves back to the partnumber box which is cleared and the datagrid is reset ready for the next number.

It works really well and the users are happy with it so I think it is a bit harsh criticising the interface when you have not seen it and do not know the context.

The only issue I have with the program, which I was hoping for some assistance with, is the one described in my original post. An example of when this problem might occur is when the counter says "red taps, 5" which the user enters, but then the counter says "sorry I meant blue".

 

[bbuk]

A little further information. When the problem occurs, ie the cursor is flashing in txtPartDesc but it acts as though it does not have the focus (even though the code in the GotFocus sub has run), the click event has not fired. If I then click anywhee on the form the click event for txtPArtDesc fires and the txtbox accepts keyboard input again.

 

[HughLerwill]

>It works really well
but something is wrong with it!

>3860 partnumbers ... a drop down box is not really practical
perhaps it would be practical if you had a previous dropdown listing 'taps', 'pipes', 'tiles', 'bricks' etc.
Your final drop down could then list red taps, blue taps etc.

>The only issue I have with the program
May be that you are trying to implement a non intuitive/ non standard user interface ie. insisting the user press 'enter' to confirm.

 

[bbuk]

Here is a little of our product listing - it doesn't really break down into simple categories as you suggest.

766-100-560 Distributor
766-100-562 Pipes
766-100-570 Control plate bushing
766-100-583 85x70x0.5 Washer
766-100-593 Motor Pulley Acessories
766-100-598 Cover
766-100-608 Mounting head protection cover USE 766-101-608
766-100-640 RAC bead breaker adjuster
766-100-641 Telescope spring
766-100-642 Racing bead break cylinder rod
766-100-643 Bead breaker bearing pad
766-100-653 Tyre inflator
766-100-654 Rubber Bead Breaker pads
766-100-661 Self centreing gear for Sicam tyre changers
766-100-663 18 Pressure Chamber for Tyre Changer"
766-100-683 Column base
766-100-685 Bead Breaker Cylinder - Chgd to 766-102-532
766-100-689 Shockproof washer
766-100-696 Piston control box
766-100-708 Pin
766-100-710 Switch assembly for MS66IT
766-100-722 Pulley Accessory - Motor Pulley
766-100-742 M/C chuck bearing upper replaced by 766-103-380""
766-100-743 Bead breaker pin
766-100-768 Nylon Washers (with square hole)
766-100-770 Mounting Head for MS43-66IT
766-100-776 Sticker
766-100-780 Sliding Arm Protection Pad
766-100-781 Roller for mounting head
766-100-815 WEDGE CAP
766-100-819 Toothed section for MS43P
766-100-833 Clamp Plate
766-100-843 Handle

I don't understand what is non-intuitive about using enter to move between fields in a repetitive data entry application:

Type part number, press enter
Type Qty, press enter
Type part number, press enter
Type Qty, press enter .....

Why involve the mouse? I just need to handle a user who makes a mistake and chooses to use the mouse to try to correct it when he could have simply entered a 0 count and not used the mouse

 

[bbuk]

Solved:

Turns out it is a known bug if a msgbox is used in a valdate event. I found the answer over at

http://www.xtremevbtalk.com.

See microsoft KB - Q240749

Thanks for the kicking - I've learnt a lesson and that is to search more widely for my answers.

 

[strongm]

>I don't understand what is non-intuitive

It's not that it is non-intuitive, it is that it is non-standard (and it is by being non-standard you have given yourself a problem).

The Windows GUI standard says, if using keyboard input, a form or dialog would use TAB to move between fields and ENTER would execute the default command button, assuming you have one (which in your case would be something like Save Data or similar).

However you have made two design decisions that are the root cause of the problem you presented here
1) You are treating editing each of part number and of quantity as an atomic operation, where really it is the combination of the part number and and quantity together that make up the data transaction
2) You are overloading the functionality of ENTER so that it a) marks a field as modified b) changes fields c) confirms commitment of the whole transaction

And so you have to jump through hoops to determine which particular function the user meant when they press (or don't press) Enter

If you stuck with the standards then you wouldn't have the problem

And that's what I was getting at when I mentioned the possibility of redesigning the interface a bit

 

[bbuk]

Thnaks for your input strongm

I fully agree that using the tab key would be the standard way to move between fields, but what I have here is a number of field engineers who are called in to the office to carry ou the stock take function - these are not people who constantly use a standard gui. From observing them using the interface on the machines they repair they always use the mouse to move between fields although they could Tab. Clearly in this application working on a laptop with a nipple this would be a very slow process. Because they don't routinely use they tab key I made a conscious decision against relying on it (in fact the tab key does still move between fields and I use it personally). I don't have a 'Save' command button because I want to keep command buttons to a minimum to avoid confusion!

In any case I have to validate the users intentions if he leaves the qty box without storing the value - does he really want to abondon that value or has he forgotten to store it?

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

I have used your instructive posts and code samples in this forum many, many times to solve my problems but I think on this occassion we will have to agree to disagree.

Andy

 

[strongm]

>agree to disagree

Looks like it

There can be good reasons why we might deviate from standard - but are you really saying that an interface that is forced to ask the user what the heck they are actually doing is a well-designed one?

 

[bbuk]

I think perfection is one thing in life something which is rarely achievable, but I think a 'good' interface is one which takes into account the target user group in applying the standards.

I would say that seeking confirmation when a user does something which has consequences which they might not have intended is very common. Consider viewing a text file in notepad. The user inadvertently types a character. When the program is closed the question is asked - do you want to save changes? With your argument the program assumes that if the user had wanted to save the changes he would have done it before closing the file, therefore the changes are lost – OK but what if the character was intended to correct a spelling for example?

 

[strongm]

>seeking confirmation when a user does something which has consequences which they might not have intended

Sure, when there is unavoidable ambiguity a program might need to check what the user intended - but my point is that you have specifically designed in the ambiguity of an action, thus forcing the necessity of the confirmation. Remove the ambiguity of the action (navigating away from the qty box) and you remove any need for the question.

 

[BobRodes]

While I take your points, bbuk, I still agree with strongm here. I would also add that the fact that your users haven't worked within the context of existing UI standards isn't a reason to deviate from them in and of itself.

 

[bbuk]

You say I am deviating from existing UI standards but I could have used MS Access to collect this data. There the enter key can be designated to do nothing, move between fields, move between records or create a ne line in the text box. Maybe the deviation is not in using the enter key to move but in using it in different ways in each box. i.e. move from the part number to qty but save and move from qty to part number. Would it be more standard to have a 'save' command button so the enter key goes
move from txtPartNo to txtQty
move from txtxQty to cmdSave
enter to Save and move to txtPartNo etc

I deliberately did not include a save button because I wanted to dissuade the user from using the mouse, but I still have to allow for this otherwise you get into the whole other argument about how much control you allow the user to have - debated at some length in other threads here. I think if I prevented the user from clicking outside the Qty box this would be interpreted as a lock-up by my users.

As an experiment I asked three of the people who will use the program if they prefered to use the enter key or the tab key to move between fields. Each of them said 'thewhat key' - 'you know the one with the opposing arrows' yielded either 'oh yes I wondered what that was for' or 'I've never noticed that key'.

This is an interesting point for me which boils down to which takes preference - sticking to conventional standards or tailoring the interface to suit the user group.

I am not a professional programmer and have never had training in applying the standards maybe that is why my viewpoint is varying from the professionals here? Maybe I'm not wrong just different

 

[HughLerwill]

>these are not people who constantly use a standard gui
All the more reason for not exposing them to a non stardard one.
If you let your programming style be affected by users with limited computer experience you are utimately not doing your users any favours (they will stay inexperienced) and coding will become complicated for you.
If users are inexperienced place a little help panel (in a label) at the foot of forms describing the interface. eg "Use the Tab key to move between fields. Press Return or click Ok when edit is complete". On pressing Return and just before the form closes you could then pop up a message saying "Do you really want Qty PartNos"? and give the opportunity to re-edit.