The weird thing on my other access the code is exactly the same except for a different form, and it works perfectly. I have a calculated textbox on the mainform that shows the sum of the subform continuous form. I have tried various methods, and textbox is just not updating at all.
Calculated textbox not recalculating, refreshing, or updating (1 Viewer)
- Thread starter TxStrob
- Start date
- Local time
- Today, 12:58
- Joined
- Oct 29, 2018
- Messages
- 21,454
Hi. Have you tried all the suggestions given to you in your other thread?
Yes, and I have those suggestions in my forum already.
I am just looking for a sample suggestion to try out.
Description of Subform (continuous form)
The quantity field for each row used to be user enter. Now it is automated. I have a textbox where you enter any number, and a combo box to pick a number. The total field shows calculated value.
Mainform:
There is a text box that shows the sum of all totals from the subform. I notice if you goto the total fields on the subform, and manually enter a number after pressing enter it will update. The problem is I don't have an on enter event. How can I get the textbox on the main form to let it know an automated change has occurred in the total textbox?
Description of Subform (continuous form)
The quantity field for each row used to be user enter. Now it is automated. I have a textbox where you enter any number, and a combo box to pick a number. The total field shows calculated value.
Mainform:
There is a text box that shows the sum of all totals from the subform. I notice if you goto the total fields on the subform, and manually enter a number after pressing enter it will update. The problem is I don't have an on enter event. How can I get the textbox on the main form to let it know an automated change has occurred in the total textbox?
- Local time
- Today, 12:58
- Joined
- Oct 29, 2018
- Messages
- 21,454
Hi. Is it behaving the same way as the demo I posted here?
I attached an image of what it looks, except my mines is done through vba for fd1 and fd2.
me.total = me.fd1 + me.fd2
The sum field will not recognize there was a change in total field. If I did place my cursor in the total field and type 38, and press enter. Then it will capture the change.
It would take me time to recreate the demo with all the qry, table, and relationships. Hopefully the picture makes sense
Attachments
-
Capture.JPG
Gasman
Enthusiastic Amateur
- Local time
- Today, 20:58
- Joined
- Sep 21, 2011
- Messages
- 14,237
So does the number of rows update when you add a new record?
I must say, for such a simple form, I'm sure a simple small db could have been created so people could see *exactly* what the form contains?
I must say, for such a simple form, I'm sure a simple small db could have been created so people could see *exactly* what the form contains?
Last edited:
So does the number of rows update when you add a new record?
I must say, for such a simple form, I'm sure a simple small db could have been created so people could see *exactly* what the form contains?
Yes that works perfectly, my form is much more complex then this one. The image of it is the blueprint of my form. Everything works perfectly except for the sum field not updating, after the value changes the in the total field. It does update if you place your cursor in the total field, and you enter the number manually. If you enter the values in fld 1 and fld2 the sum total does not update.
You're not helping us to help you. If I'm not mistaken, at least 3 people have requested an upload of some sort - either a simple mock up that contains your form and whatever else is needed plus you've been given a link to a function for randomizing data to provide privacy. Failing either of those, I suspect there's a lack of interest given your opposition to that. I followed the link in post 6 here and didn't find it to be of much help - unless you go to the beginning of that thread. However, the link to the beginning isn't obvious so here it is; perhaps it will provide some insight.
https://www.access-programmers.co.uk/forums/showthread.php?p=1648174
https://www.access-programmers.co.uk/forums/showthread.php?p=1648174
- Local time
- Today, 14:58
- Joined
- Feb 28, 2001
- Messages
- 27,146
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
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
