How to always set focus on the control on parent form after entering data in the subform (2 Viewers)

[Albert D. Kallal]

A few things - but just a quick look here at what we have so far?
First, don't use on-current - avoid if possible.

Next up, a goToControl is placed/moved to the sub form.
I suggest to NOT do this.

So, keep/write ALL of the code in the main form - don't use the "UI" to set focus in sub form.

You trying to do "data processing" by using the UI. The UI is for the "user", not data procesisng code!

If you start writing a bunch of UI code based on setfocus, and updating text boxes?

That is going to be flicker city!!!

Worse, any kind of timer control etc. - again going to cause issues!

Hence, do NOT do the insert by filing out controls into the sub form - but insert into a recordset.

And BETTER is to use recordSetClone, not the recordset

Why?
Because the forms reocrdset is tied to the UI, and recordset clone is NOT!!!!

So, get/grab/use the existing sub form recordset

The above is good "general" advice here.

Try to "avoid" using the "UI" for database operations. So, things like setting focus from the main form to sub form. and then moving the sub form to a new reocrd!!! - And all the while the main Access processor thread is "stacking" up all kinds of re-draw events, set focus events into that "behind the scenes UI thread update system.

No matter how you spin this?
It's going to be junkiy....

So, new logic:

Scan occures in main form.

Process the scan data, insert into the sub form recordset (recordset clone) - NOT the UI!!!

do a subform.requrey to show the new row you inserted (via code directly into hte table), and turns out you already have that!!!

Then, consider a setfocus back to the control that holds/expects the scan.

I assume the scanner does either a tab, or a enter key for you - make sure there is at least one other control on that main form to receive the focus after that tab key (hit by scanner for you) exists to accept the focus...

So, quick glance at the code, some "air code" here?

First up, mID -- that conflicts with Mid() - reserved word - hence use me!mID....

AIR code warning here....

Public Sub txtProductCode_AfterUpdate()
    
    
    Dim lngProdID           As Long
    Dim sReturn$            ' as string
    Dim varValue            As Variant
    
    Dim rstSubFormData      As DAO.Recordset
    
    
    
    If Not (IsNull(Me!ID)) Then
                
        Set rstSubFormData = Me![sfrmPosLineDetails Subform].Form.RecordsetClone
        
        With rstSubFormData
            .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
            
            .Update
        End With
            
    End If
        
    Me.sfrmPosLineDetails_Subform.Requery
      
    ' clean up main form controls - emptry, ready for next scan
    Me.txtProductCode = Null
    Me.txtProductCode.SetFocus


End Sub

Try the above approach.

So, the lesson of the day?

Don't use the UI for data processing - write such processing - you eliminate boatloads of screen flicker and updates as a nice bonus...

When possible, and adding data?
Use RecordSetClone in place of RecordSet - I can expand on why this is a better/good design approach..

R
Albert

 

[Albert D. Kallal]

Excellent advice, Albert. It makes a lot of sense. I did previously mention about the barcode reader appending an enter or tab key, but no one paid attention to that. We were all drowning in a glass of water figuring out if focus was in the subform, and struggling to get it back up to the main form for the next scan, or finalize the order. Inserting the line item record from the main form and requerying the subform avoids jumping through all those UI hoops.

Excellent!
And the UI will be smooth as butter for this operation......

And like everyone else here?
Just adding my 2 cents worth here.....

As noted, if there is only one control on the main form, and when that "scanner keyboard" hits tab for you? Make sure there is another control on the main form for focus to jump into (there probably is).....

R
Albert

 

[KitaYama]

make sure there is at least one other control on that main form to receive the focus after that tab key (hit by scanner for you) exists to accept the focus...

While I enjoyed reading your reply, may I ask why you suggested above?
You can have a form with only one text box, and when you type something and press Enter (or scan a barcode that ends with Enter), the AfterUpdate event still fires, even though there’s no other control on the form for the focus to move to.

I actually was following this thread and was wondering why no-one suggested to set the "Tab Stop" property of all objects (subform included) on the main form to "No" . I think that's a no-code solution.

 

[Albert D. Kallal]

While I enjoyed reading your reply, may I ask why you suggested above?
You can have a form with only one text box, and when you type something and press Enter (or scan a barcode that ends with Enter), the AfterUpdate event still fires, even though there’s no other control on the form for the focus to move to.

I actually was following this thread and was wondering why no-one suggested to set the "Tab Stop" property of all objects (subform included) on the main form to "No" . I think that's a no-code solution.

As a general rule, no, if there are no other controls on that form, then hitting tab will not fire the after update event.

However, in this case, we MOST certainly have another control on the form - that's the sub form control!

And that means that focus is now moving from main form to sub form. This we really don't want, since it will do several things.

First, it will trigger the forms after update, and will trigger a automatic save of the main form record. (it's possible that that the main form is un-bound).

So, having a text box after the text box (that we scanning into), will allow focus to change "out" of the current text box, and that will ensure that the after update triggers (of the text box - NOT the after update of the form!!!). And as noted, we really don't want the focus moving to the sub form.

Now, there are some caveats to the above.
First, if the main form is bound, and you "forget" to set the form's cycle to current record, then a tab in most (many??) cases will trigger an advance to the next record!!! - we don't want that!!! (BUT, as such, then control after update does trigger).

But, if the form is un-bound (which it might be), then hitting tab has no place to go (to the next control), and thus the text box after update does not trigger.

So, the FYI here? It's not a simple 0 or 1 answer, but at the end of the day, having a control that follows the text box will eliminate a good number of potential issues - often such issues can be worked around, or dealt with.

But, all in all, if you have a text box that follows the control - even a un-bound one, then I can think of a "list" of possible issues that crop up - all are eliminated if you have that control on the main form to capture the focus after the scan text box exits focus - as it surely will. Without any other controls on that form, then as noted, things are not so cut and dry.

You can try a test database - start out with a un-bound form with one simple text box - tab will not fire after update. if you then "bind" the form to a table, and bind the text box, then hitting tab will trigger after update, trigger a data save, and move to the next record!!!

(none of which we want to occur!!!).

So, a simple adding of a text box (or ensuring there are other controls on the main form)?
This is a 100% code free solution......


R
Albert

 

[KitaYama]

if there are no other controls on that form, then hitting tab will not fire the after update event.

It will. The AfterUpdate will fire even if there's only one text box in a form. Give it a try.

I'm at work and haven't time to read all the rest of your reply. I'll check it during lunch time. Thanks for taking your time and replying.

 

[Albert D. Kallal]

It will. The AfterUpdate will fire even if there's only one text box in a form. Give it a try.

I'm at work and haven't time to read all the rest of your reply. I'll check it during lunch time. Thanks for taking your time and replying.

Yes, you are correct!!!
(happy to be corrected on this issue == thanks for the follow up).

So, ignore my "narrative" on needing some extra textbox or control to receive the focus - not required.

So, good = don't try to use the UI for this - use recordset data processing.
So, bad = my bad is the part about needing that extra control? Nope - as noted, it's not required.....


R
Albert

 

[nector]

Many thanks to you all our valuable professionals we appreciate all your contribution and I'm glad that to say that through your help we managed to sort it out and its working ok.