The real problem is that for reasons unknown, Access doesn't have a way to tell you how big your text string will be when displayed. There IS a subroutine to do this for printed reports, but it doesn't work for displayed items. Therefore you cannot easily know exactly how big the text will be unless you use a non-proportional font like Courier New (which has a fixed width).
At least in theory, a Courier New character on-screen with a font size = 72 points occupies one inch by 3/4 inch. That height is also 1440 twips because Access forms and reports use twips as a size measurement, 1440 per inch. So 20 twips per point. Somewhere in there is enough info so that you can compute the size of your string for non-proportional font Courier New simply by knowing the number of bytes in the string, i.e. the LEN() function.
I don't know the nominal sizes of other fonts. You would have to measure any other fonts you wanted to use AND if you used a proportional font, then the length required would be less than your computed size due to non-uniform character sizes. Also, if you have an option to turn off kerning, that would affect string length.
Kerning is the practice of "squishing" letters together if there is some room, like for example consider "Te" as the beginning of a word. The little e can be moved closer to the capital T because the e fits under the T. Lots of letters have the ability. Capital F also can have some kerning. So if the font allows kerning, you will compute too great a width.
As to WHEN you do this, I concur with bob fitz that OnCurrent & AfterUpdate are good, but if there is any interdependence between text boxes (i.e. make a change to control X and the contents of the text box change), other events such as OnChange or LostFocus might also be involved.