Suppress Output message...again

Christine Pearc

Christine
Local time
Today, 21:44
Joined
May 13, 2004
Messages
111
Not sure why nobody is responding to this question, but I've been trying to find an answer since my post of 11 October and a previous one 1 year ago. I'm REALLY desparate for a solution -- there MUST be a cure!! :confused:

The problem is that, when you do a "DoCmd.OutputTo acOutputReport", the message "Now outputting... <file name and path>. I don't want this message to display, especially since there is a Cancel button on it!

Try as I will, I can't get people to stop pressing the da&!^% Cancel button (cheeky prats), which when pressed results in a blank report being sent with the email...and then the complaints come in about problems with the code...sigh!

DoCmd.SetWarnings False doesn't work. Also tried creating another form with a Timer event (found on the web to deal with the problem), but that doesn't work either as they still have time to press Cancel.

At wits end,
Christine
 
Christine Pearc said:
Not sure why nobody is responding to this question, ....

Maybe no one has a solution ???
 
Have you tried a transferspreadsheet thing?
 
Ken, do you mean exporting it as an Excel spreadsheet? If so, I can't tried that, because the output is to a Snapshot file and many people here don't know Excel and/or don't have it. This is so frustrating because, when you want to use automation you'd think such simple tasks like saving could be....er...automated! Surely I'm not the only one with this problem?!
 
Hum...

I would think that after I cancel'ed once and got a blank report, I'd learn to let it run...

(Sorry that I'm not much help...)
 
There's a similar problem with Outlook's security warning ("...another program is attempting to send email...). I've written a procedure, provide on-line help, conducted training, display message boxes instructions, etc. ...to no avail - someone always messes up the works. Thanks for responding anyway, Ken.
 
Christine,

I have some similar code that outputs over a hundred reports to successive recipients (winzipping and password protecting before attaching them to the email). I have looked at suppressing this cancel box too. It is a windows message and doesn't appear to be associated with Access - hence the reason you can't disable it through standard Access functionality. The only thing that I could think of was trying to intercept the attempt to cancel and pop up a message which says "are you sure"... but as yet I don't have the time to look further. Something slightly more dangerous might be to disable keystrokes at the time of outputting?! I'd never be brave enough to attempt something like this though!!

Please repost if you find a resolution and I will do likewise.

J.
 
James, good to hear from you..I was begining to think I was all alone on this one!

The only thing I've found on a HUGE number of web searches is code written by Dev Ashish at http://www.mvps.org/access/api/api0037.htm. It doesn't profess to be perfect, however, I can't get it to work at all: the "hidden" form he suggests lays BEHIND the printing dialog, which isn't any good! I am, however, calling modules from the form that sets up for printing, so maybe that's the problem. Try the code and please let me know how you get on. Perhaps between the 2 of us....

Ta,
Christine
 
One interesting observation... DoCmd.OutputTo acOutputTable doesn't come up with the message that is annoying us, which must mean that it isn't necessarily a windows dialogue and is probably associated specifically with the Reports themselves. I have asked an Access Guru (good mate) to take a look at this as well. If anyone can help us, he can. Will take a look at that website now.
 
Hum, James, I'm not so sure it isn't associated with the report. Here is specifcally what I'm doing/getting:

DoCmd.OutputTo acReport, "rpt CAR Form", "SnapshotFormat(*.snp)", "M:\Public\CAR\rpt CAR.snp", False

Then, the dialog box:
Printing… Now outputting page 1 of ‘Report’ to the file ‘M:\Public\rpt CAR.snp’. Below this is the infamous Cancel button.
 
Opps...sent that before I was ready. Anyway, just wanted to say I won't be back until Monday. I hope your friend as some good news for us.
Cheers,
Christine
 
Christine,

The guru came back with the following...

"The verdict on the cancel button is that neither the docmd.setwarnings nor the application.echo have any affect. This one has me stumped! The cancel option is modal, and SO modal that it's impossible to override.
Unless you find a cunning way to lose it your only option is to rethink the whole concept, like maybe throwing it all out to a new Excel object then printing that? I can send you a stack of formatting code to get the spreadsheet looking right, and I suspect it won't take much longer than your current method.
If I have any brainwaves I'll let you know, but I'm not hopeful!"


Not very promising I'm afraid!! Looks like you may want to follow Ken's original suggestion below. At least by outputting to excel it doesn't offer the Cancel option.

J.
 
James, I kinda figured that we'd hit a wall; thank your friend for me.

Excel isn't an option for our company. I'm going to try to simplify my report so that the save operation is quicker and thus, the Cancel button won't be in front of users so long.

In the meantime, have you had the chance to play with the code at Dev Ashish at http://www.mvps.org/access/api/api0037.htm? I'm afraid that might be our only help. Please let me know if you can get it to work.

Ta,
Christine
 
Hey Christine,

Yeah, I took a look at that code. I really like what he has done. It isn't really necessary for my circumstances, because I have multiple dialogue boxes coming up as I go through a loop, and each time the printing dialogue comes up it is only for a fraction of a second. If you have a report that takes a long time to generate then I can really see some potential in it... it is probably your best bet!!

When it is working correctly the printing dialogue will come up for about 1/2 sec and then minimise to the bottom left of your screen. It is very clever in the way that it works.

I will try and explain his process again as simply as I can:

  • Create a subform with nothing on it. The subform should be a pop-up with a timer event set to 300. The on timer parameter should be an event procedure with the line "Call sWatchAccess(Application.hWndAccessApp)".

  • Create a form with a command button that will output your report.
    In the same form drag and drop your subform (above). Go to the properties of this subform and ensure that it is set to visible (I had to do this for some reason?!).

  • Paste the remainder of his code into a module and save it.

  • Run it.

If you get it to work you could probably experiment with the visibility properties of your supposed 'hidden' form to try and make it stay hidden, but this didn't work for me. Maybe just add some text to say "processing... please wait".

HTH

James
 
Hey Christine,

Did I ever suggest the technique that I use to overcome this problem?

I just trap for the interruption code and output a message that tells them to wait.

Code:
    If Err = 2501 Then
        MsgBox "You have attempted to cancel the output of the emails." & vbCrLf & _
            "This will cause major problems." & vbCrLf & _
            "Please be Patient"
        Resume
    End If

Another good problem to trap is exceeding the limit on your mailbox...

Code:
    If Err = -2147467259 Then
        MsgBox "You have exceeded the storage limit on your mail box. Please delete some items before clicking OK", vbOKOnly
        Resume
    End If

Just add both to your error-trapping routine and you shouldn't get any more problems.

You may want to send yourself a notification email at the same time that someone tries it... so that you can walk over and give them a clip around the ear!! :D

J.
 

Users who are viewing this thread

Back
Top Bottom