TxStrob
Failure to update that text box most likely means that you haven't used the right events to act as triggers for the computation. Just because you have a formula defining the value of a text box doesn't mean it gets re-evaluated when some other form does something.
The only time a text box gets re-evaluated implicitly is during the Form_Current routine for the form holding that text box. If something happens to the sub-form, that is literally not related to the main form, mechanistically. Oh, sure, there can be a link between a field in the sub-form and a field on the main form, as a parent/child sort of thing. But to Access, forms are independent most of the time even in a parent/sub case. And the nature of the parent/child relationship is often one-way. Change the parent, the child changes. But change the child? The parent doesn't know about it most of the time.
This next question is rhetorical: When does any value in the sub-form change? Because that is the event that should also trigger your recompute.
If the event in the sub-form didn't originate from a main-form action, then you have no event and will have to contrive one. There are various ways to do this. The simplest method might be to find the parent form of the sub-form so that after a sub-form change, you relinquish control back to the main form. It might be so simple as setting the focus on a control on the parent form.
This change from sub-form to parent form involves a Deactivate event (on the sub) and an Activate event (on the main). That might be a viable place for what you want, but it might not be the
only place you would want to put this computation. Since you didn't post a sample DB, we can't tell what other events might be candidates.
Look in the middle of the page at this link for the Activate and Deactivate events.
https://support.office.com/en-us/ar...ects-e76fbbfe-6180-4a52-8787-ce86553682f9#bm3