My 2 cents. First is to remove the control source property from this and any other combo that's used to filter data. As is, you're not just altering subform records based on the selection, you're altering the value associated with the related data - e.g. if a date is related to that combo value and you choose a different value, that date now becomes related to the new value as you're changing it. Search combos should not be bound. Perhaps your data has been compromised as a result.
Then I'd remove the calculation from the textbox to the after update event of the combo and remove the embedded macro. In that event, I'd also deal with the possibility that some calculations return Null, so wrap the DLookup in the Nz function as in
Me.Text43 = Nz(DLookup("[Qty In Stock]", "[Products_T]", "[GG Product No]= " & Me.GG_Product_No), 0)
You don't need to use Forms! reference when the field is on the same form.
Above all, I'd try to have the calculation performed by the form query, except for the fact that your table is the form recordsource. I almost never do this because there's little flexibility, or control over what happens to the table record. If you can do that, you won't need to DLookup at all. I find that sometimes the calc takes a long time and the textbox disappears. Perhaps there are other embedded macros or events that play into that.
Lastly (about the form or its properties), you should adopt a naming practice. Text43 is a lousy name for a control. I realize it's the way Access works, but you don't have to settle for it.
http://access.mvps.org/access/general/gen0012.htm
https://www.access-programmers.co.uk...d.php?t=225837
What not to use in names
- http://allenbrowne.com/AppIssueBadWord.html
Perhaps most important, have Option Explicit at the top of every module. In fact, turn it on going forward (vb editor, Tools, Options & find "require variable declaration")
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.