UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Opening A Report From A Form, Access 2003    
 
   
shadow
post Feb 22 2018, 09:55 AM
Post#1



Posts: 243
Joined: 19-April 04
From: Toronto


It's quite common to use a form with some controls that the user can fill out to launch a report. The details of the report will be based on selections that the user made in the form.

In my applications, I almost never have a print button right on the form that sends the report to the printer. Rather, I prefer for users to preview the form in case some of the choices made need to be changed.

This works just fine. BUT, there is often code in the report with some programming logic that will change details of the report based on the user's decision. When the user clicks the preview button, views the report and then clicks the printer in the toolbar, everything is ok. However, I've had the user actually send the report to the screen, CLOSE the form (!) and then print and then get all kinds of errors and possibly a dreaded runtime error because the code cannot reference the form anymore.

My question is if there is a solution that people use for this fairly common situation?

I could prevent it by setting the report to pop up so the user can't click anything till it's dismissed (great way to annoy users), OR to put some prevention in the form's On Close to disallow closing if the report is open. However, what I'm looking for is a way to tell the report to print what's already on the screen rather than re-rendering it and running the code all over again. I would see that as more ideal if it's possible.

Thank you

Shadow
Go to the top of the page
 
ranman256
post Feb 22 2018, 10:04 AM
Post#2



Posts: 861
Joined: 25-April 14



you should always print to screen, then the user can print to printer if needed.
The form should be the 'index' of what is on the report. Usu the current record is the item to print.
My users understand this...report on the record you are on.

The report will print as it prints. It dont cost nuthin to start over at page 1 and print thru page N.

Go to the top of the page
 
doctor9
post Feb 22 2018, 10:12 AM
Post#3


UtterAccess Editor
Posts: 18,324
Joined: 29-March 05
From: Wisconsin


Shadow,

Your description isn't very detailed, but if a report has errors because a specific form is closed, then it makes sense to open the report from a control on the form.

If the errors are based on the report's recordsource query depending on the form being open, consider re-designing the query so it does not depend on the form. For example, I have a form where I enter the bills that my company pays. The report for "print this record" is set up to print ALL bills. The button that opens the report is on the Bills form, and uses the WhereCondition argument to FILTER the report:

CODE
DoCmd.OpenReport "rptBillPrintout", acPreview, , "[BillID]=" & Me.BillID


That way, when the user clicks the button to print the report, the data is filtered to just the form's current record. Added bonus: the same report can also be used to show a set of bills from a date range by using a different argument than "[BillID]=" & Me.BillID.

In short, wherever you have code that refers to the form, find a way to either remove the code by filtering the data and have the code refer to the report's data instead.

Hope this helps,

Dennis

--------------------
(;,;) Li'l Cthulu says: Please talk about what you're trying to do, as well as how you're doing it.
Changing your real table name to "Table1" and your real form name to "Form1" in your posts makes it more difficult to understand what's going on, not easier.
Guidelines for Posting Questions
Go to the top of the page
 
shadow
post Feb 22 2018, 10:33 AM
Post#4



Posts: 243
Joined: 19-April 04
From: Toronto


Ok, looks like my description failed smile.gif

The report is doing a lot more than displaying data from a table or query. You wouldn't really need much code in the OnFormat event of the report if that's what it's doing. The report has a lot of code that hides or shows different controls, shows notes that the user entered on the form and so on. So, the code in the report itself has a lot of references to the form. That's why it doesn't want to print if the user closed the form after launching the preview.

Just to repeat: It seems that printing a report that's being previewed to the screen rerenders the whole report and executes all the code all over again rather than literally taking what's on the screen and dumping to printer. As I said, I can programatically prevent the user from closing the form but I was wondering if there's a better way.

I hope this is more clear.

Thanks again!
Go to the top of the page
 
doctor9
post Feb 22 2018, 10:35 AM
Post#5


UtterAccess Editor
Posts: 18,324
Joined: 29-March 05
From: Wisconsin


Shadow,

Can you give a specific example of report code that depends on a form being open, and why you can't refer to the report data instead? That would help clarify your problem.

Dennis

--------------------
(;,;) Li'l Cthulu says: Please talk about what you're trying to do, as well as how you're doing it.
Changing your real table name to "Table1" and your real form name to "Form1" in your posts makes it more difficult to understand what's going on, not easier.
Guidelines for Posting Questions
Go to the top of the page
 
shadow
post Feb 22 2018, 11:11 AM
Post#6



Posts: 243
Joined: 19-April 04
From: Toronto


Ok, I created a simple and silly mockup to demonstrate my problem.

1) Open the form (should launch on it's own)

2) Enter some data in the text box and make a selection on the option group.

3) Click the preview report button.

It should display a report with a few lines of text on it. If you print it on your printer everything's fine.

NOW close the form and then try to print. The code will execute again with several references to the now-closed form and you'll get an error.

You'll see in the report's design view that the code is based on choices the user makes at runtime rather than just data in a table or query.

I hope this clarifies my question and I appreciate your help.


Attached File(s)
Attached File  ReportIssue.zip ( 19.72K )Number of downloads: 6
 
Go to the top of the page
 
zaxbat
post Feb 22 2018, 11:34 AM
Post#7



Posts: 932
Joined: 26-January 06
From: .....the wiregrass (either you know or you don't)


I see this problem a lot with my reports because I have a lot of VBA code helping to create the report. But, Nope, I don't have any other solution so far except to open the report in pop up modal so the user cannot muk things up.

Just had a thought though.....

Might be you could move all of your VBA report support code to a global/public module (take it out of the form VBA module)....in that way the code should be available to call from anywhere at any time and might just work for you....sounds to be frought with danger nonetheless.....hmmmm
This post has been edited by zaxbat: Feb 22 2018, 11:50 AM

--------------------
Kindest regards, and Cheers!
ZAX

A picture is worth a thousand words and a zipped DB is worth a thousand pictures.
Oh, and....please don't disappear into the Twilight Zone.... Holler back with your results!
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    18th June 2018 - 02:35 PM