How to always set focus on the control on parent form after entering data in the subform

nectorch

Member
Local time
Today, 15:48
Joined
Aug 4, 2021
Messages
61
Hi

I thought this was an easy task, but has proved not. The people scan the barcode on the parent form on the control called txtProductCode that works fine no issues data is transfered to the subform, but the second scan for the next line item the cursor does not set focus on txtProductCode users have to click the control txtProductCodesor for the scanner to scan in the right box. Is there a way to make sure that the cursor is always set focus on txtProductCode.

I have tried the following nothing is working

form current event

Me.txtProductCode.setfus

It does not work
 
> data is transferred to the subform
Please show us that code. It appears that this code is setting focus away from the parent form.
 
Code:
Public Sub txtProductCode_AfterUpdate()
Dim lngProdID As Long
Dim sReturn$, varValue As Variant
    If Not (IsNull(mID)) Then
        'DoCmd.GoToControl "sfrmPosLineDetails Subform"
              
        With Me![sfrmPosLineDetails Subform].Form
            .Recordset.AddNew
            
            ![ProductID] = mID
            ![QtySold] = 1
            
            sReturn = DLookup("ProductName & '|' & vatCatCd & '|' & dftPrc & '|' & VAT", _
                            "tblProducts", _
                            "BarCode = '" & Me.txtProductCode & "'")
            varValue = Split(sReturn, "|")
            
            ![ProductName] = varValue(0)
            ![TaxClassA] = varValue(1)
            ![SellingPrice] = varValue(2)
            ![Tax] = varValue(3)
                      
            ![RRP] = 0
            
            If Me.Dirty = True Then
        ' Save the current record
        Me.Dirty = False
    End If
        End With
    'DoCmd.GoToRecord , , acNewRec
        
    End If
    Me.sfrmPosLineDetails_Subform.Requery
      
    Me.txtProductCode = Null
    Me.txtProductCode.SetFocus
End Sub
 
Try changing:
Me.txtProductCode.SetFocus
To
Docmd.GotoControl "txtProductCode"
At the end of the procedure.
 
Try this instead of the last line:
Me.Parent.SetFocus
Me.Parent.txtProductCode.SetFocus
 
Me.Parent.txtProductCode.SetFocus
That is not going to work since this code is obviously being called from the main form and in fact from txtProductCode
Code:
txtProductCode_AfterUpdate()
 
My guess is that this after update event is not even firing. The OP needs to test. If the OP is using a barcode reader to update txtProductCode the afterupdate never fires. After update events do not fire when the control is updated via code vice user action.

That would be my natural conclusion too, but they say 'The people scan the barcode on the parent form on the control called txtProductCode that works fine no issues data is transfered to the subform', which suggests that the AfterUpdate event procedure's code is being executed. What surprises me is that the event procedure is being executed for the first scan, not that it is apparently not for subsequent scans.

Clearly they should set a breakpoint at the top of the procedure and step into the code to see what is being executed, and what isn't.
 
What surprises me is that the event procedure is being executed for the first scan, not that it is apparently not for subsequent scans.
That is a mistake on my part. The scanner emulates the keyboard so the after update does fire. I think that is the standard way to do it.
 
My next guess is that the focus is first set and then something causes the focus to move away. Such as a pending event or pending code. To test

Code:
Me.txtProductCode = Null
DoEvents
Me.txtProductCode.SetFocus
Msgbox "Check to see if focus is set"

One thing that can cause the main form to immediately lose focus is when a subfom is set to allowadditions = false and there are no current records in the subform. See discussion

That issue will drive you nuts because the active control executes the code but then says it is not the active control.

If your subform has allow additions to false, try your code with allow additions to true. Then if that works and you need to simulate "disallow additions " then just lock all the controls.
 
Why jump through all those hoops when all that needs to be done is to set focus on the control in the main form with:

Code:
Private Sub YourSubformControl_AfterUpdate()
   Forms!frmMain!txtProductCode.SetFocus
End Sub
I’m not sure either if that event fires if the subform’s underlying record source is updated through code.
 
Why jump through all those hoops when all that needs to be done is to set focus on the control in the main form with:
Does not makes any sense. We must be reading two different posts. You need to look at what the OP posted. There is no "YouSubFormControl" involved. His barcode reader is updating the main form txtProductCode which is then updating the subform.
What makes you believe that this is being called from the subform? The OP did not state that? The code does not suggest that?
 
So then why doesn't set focus or DoCmd.GoToControl statement in the main form set focus on Me.txtProductCode?
In my Post #10, In my form I opened a file in an external web browser and had no problem immediately setting focus on a text control to continue entering data.
Don’t think I can answer that question without being able to step through the OP’s code, so a demo file would probably help us figure out the actual cause of the problem.
 
That was a sample placeholder name for the OP's whatever subform name he used
Thats the whole point. You seem unwilling to read the OP's post, or I do not know where you are coming up with this. There is no event being called from the subform. No such thing exist regardless of any placeholder name (I get that).
Code:
Private Sub YourSubformControl_AfterUpdate()

Clearly the OP shows this
Code:
Public Sub txtProductCode_AfterUpdate()
That clearly means the code is being called from the main form from txtProductCode

Why do you have to be so rude in your replies
I do not know. But when people try to correct me after I have provided the OP a sound idea and they provide a sensical counterpoint I am all for it. When they instead provide nonsense, i find it super annoying.
Why jump through all those hoops when all that needs to be done is to set focus on the control in the main form with

Let me make it easy for you by simplifying the code
1. The bar code reader triggers the after update in the main form
Code:
Public Sub txtProductCode_AfterUpdate()
    'code
    Me.sfrmPosLineDetails_Subform.Requery
    'code
    Me.txtProductCode.SetFocus  '(Not working as desired)
End Sub
2. The OP tries to set the focus to txtProductCode (in the main form and called from the main form)
3. For some reason the focus fails to set or my guess it gets set and then moves off

Notice there is no code being called from the subform.
Yes we all know that this should be possible.
So then why doesn't set focus or DoCmd.GoToControl statement in the main form set focus on Me.txtProductCode?
If the OP knew this, then they would not be here asking why it does not work as expected.
 
I researched this proposition and I've found a couple of references that say that code referencing a property (i.e. .VALUE or .FORM) does not necessarily activate the control. Put some code on an OnActivate event for that code to see if it will trigger. But the suggestion is that it isn't guaranteed to do so, unless you use VBA to trigger a method of the control that would potentially alter its focus.

I have run lots of code that dynamically rearranged command buttons based on a context-sensitive "button shuffler" routine that turned off command buttons that weren't applicable in that state, after which I closed the gaps left by the disabled buttons. The idea was to move the buttons to the right. Basically, a dynamic control panel. And when I shuffled the controls, NONE of them activated/became current. It sounds complex, but it looked good.
 
I think his subform became active when his parent form code executed 'With Me![sfrmPosLineDetails Subform].Form'.
Perhaps you are right, but I am not sure that it also means the subform was dirtied, since the code directly modified its recordset. If that is the case, then you would be correct to use the subform’s AfterUpdate event.

Actually, I just re-read your post, so I may have misunderstood your meaning. I am not in front of a computer now, but if you were actually referring to the AfterUpdate event of the subform control and not the actual form assigned to it, then I am not sure that it has that event. If I remember correctly, it should have an Enter and Exit events, but not sure about an AfterUpdate one.

Sent from phone…
 
This fails also

Code:
Private Sub Form_AfterUpdate()
Forms!frmPOSStocksSold!txtProductCode.SetFocus
End Sub
So, while waiting for a demo, I finally had a chance to fire up the laptop and do some tests.

It seems to me that in the AfterUpdate event of a control, that control still has the focus. So, sending or setting the focus to that same control is unnoticeable, because it already has the focus and when the focus is directed to it, nothing will appear to have changed. Now, after the code in the AfterUpdate has finished executing, that change in focus is probably getting overridden by the Tab Order (that's my guess).

In my experiment, all I had to do was send the focus away from the current control that has the focus (meaning, the one with the AfterUpdate event code) and then simply send it back to itself. When the event code is finished, that focus change seems to have stuck.

For example:
Code:
Private Sub Text1_AfterUpdate()
    Me.Text2.SetFocus
    Me.Text1.SetFocus
End Sub
Hope that helps (or makes sense)...
 
Here is the full db as requested , barcode to use are 410000100 to 410000127

POS Photo 2025.jpg
 

Attachments

Your With subform code that does a Recordset.AddNew is dirtying the subform and making it active.
So, I continued with my experiment to verify this statement. I can confirm that the subform is getting dirtied when using the With and .Recordset.Addnew. However, the original text control seems to retain the focus - meaning, the subform does not become active by using this code.

There is one peculiarity that I am encountering with this approach though. Each time I enter something in the textbox and the AfterUpdate code adds that entry to the subform, it seems my Autonumber values skips one ID each time. For example, if I enter something that gets an ID value of 2, the next one I do gets the value of 4, and so on. I'll come back if I figure out why.
 

Users who are viewing this thread

Back
Top Bottom