+ As for your code, without yours, it's fairly difficult to help you with this particular issue. Please make sure that you select your VBA Script and format it using the
[CODE/] tool.
+ Normally, you wouldn't have the report drive things on the form. However, I would look at the on_close event of the report to interact with your form.
+ Normally one would be passing the information to the report
from the form when the report is opened not pulling information from the form to the report.
There are various methods normally used to do this; however, AFIK, parameterized queries based on forms tend to be one of the more common methods followed by "Open Augments" and filters.
I do have a database where the report does drive the user interface on initial opening; however, this only because:
1) The underlying report record source is a query based on a form that collects user input. This forces the report loading to halt because the query needs information which results in the form opening (no vba :) )
2) Once the user clicks on [Submit] the form is hidden (and if the report is closed, reopens the report which because the form is already open the query runs and the reports opens); thus, allowing the report to finish loading.
3) The report's on_close event unhides the form for more user interaction if needed.
+ IMHO, your report should
not be setting record sources in the calling form - especially subform(s). The subform(s) should normally be handled by the parent form, not a report.
+ One of these threads may provide you with a few ideas on how to approach your report/interaction from a different angle:
Search results on Bytes.com Key words: [open report with current record] (read more)
when we have a bit more information about your on_load event code we can go from there if you insist on going this route.