Here is the problem. Access needs hard-and-fast rules to define the contents of something. Let's say you have two boxes, [TBBound] and [TBFormula]
You tell us that you want something computable to be placed in [TBFormula] but that you also want it to be something you can permanently and manually override. In order for that to happen, [TBFormula] must be bound to a recordset. I.e. you have to store it to permanently bind it with an override.
Let's say that [TBFormula], if not overridden, is computed from [TBBound]. When you place a value in [TBBound], you could use a TBBound_LostFocus() event to put something in [TBFormula] if it is still empty or null or blank or whatever.
Here's your dilemma. A control (such as [TBFormula]) can be unbound, bound, or computed by formula. That's it. That's all the choices you have.
If it is unbound, then it never takes on any value from an underlying recordset. You could therefore populate it from the Form_Current routine by computing from something else on the form. Like from [TBBound].
If you want to REMEMBER that for record #2 you overrode the computation, then the control must be BOUND because only bound controls have memories of what they were. If the control is purely computed (i.e. a formula), it has no place to remember anything. If it is unbound, it has no memory, either.
This is the catch. If the form calls up a new record and you don't happen to define a new value for the field., you will compute it and store it in the text box. If you save the record, you save the computed value, which acts as though it were an override value the next time that the same record comes up again.
If what I just described doesn't make sense to you, then you need to do some more reading. This is basic form-based controls 101. If this is not the behavior you wanted, you will have to find a way to "cheat" Access rules on control behavior. Or maybe decide to not really do this in the first place.
