Re: Printouts NOT coming out in order they are sent???



DoEvents right after printing the separator sheet worked!!!

Why, exactly???

I not surprised here.

You using two COMPLETE different approaches to printing the repots.

Approach #1

tell access to print the report, BUT DO NOT display it..


Approach #2

Tell access to open a report

have access wait for windows to render and display the report
(and, speed of graphics card, and all kinds of rendering has
to occur to the users screen via windows API).

Have access THEN print the report.

Then have YOUR code close the report.

You don't see a HUGE, LARGE, MASSIVE, Mount Everest difference in the above
two approaches? You don't see a tremendous difference in sending commands to
the event queue, and *your* contorl of the order of events in the above?
Oh yeah. Now that you pointed it out - huge!


The doevents command simply flushes out the event que in ms-access. In many
places in my applications I often have to insert a DoEvents command to
ensure that access has finished what it was doing..

However, you likely could solve the above by also:

a) use the SAME approach for printing all reports
(that means using docmd.openReprot, and *then* usign the
docmd.Printout..*even* for the separators).

So, don't use two complete different approaches to printing out stuff,
especially when one approach is going to wait for your display (and speed of
your graphics card) etc. to render the report,a and the other approach is
not.
Point well taken.


Access does use some threading (that a fancy term in which multiple
processors or multiple processes occur at THE SAME TIME. With a
multi-processor machine, this type of treading issue can get even worse (I
know, because I just experienced it with a large batch priming of word
documents...).



b) I would not be too surprised if you turned the visible of the report off
right away, your problem would also go away:

eg:

DoCmd.OpenReport "rptAOC-SP-905M_NonBatch", acViewPreview
Reports("rptAOC-SP-905M_NonBatch").Visible = false


Furthermore, to be consistent, you should likely make a subroutine for all
of your printing


So, you can go:

Call MyPrint ("rptSeparatorSheetSP905s",1)
Call MyPrint("rptAOC-SP-905M_NonBatch",4)
Yep. I agree with the suggestion. Thx.



Public Sub MyPrint(strRep as string,intCopies as interger)

docmd.OpenReport strRep,acViewPreView
reports(strRep).Visible = false
DoCmd.PrintOut acPrintAll, , , acHigh, intCopies, False
DoCmd.Close acReport, strRep

end sub

The above some routine idea would save you have a truckload of code.
Furthermore it would also centralize the printing approach to be exactly the
same in all cases. Thus, if you change how you print, then the change would
be the "same" every single report you send to the printer.

Perhaps in the future you want a flag or a button you set to not print, but
save as a PDF, and email....
That's right. Am sending lots of PDF copies of reports attached to
automated eMails whose purpose is to keep my customers in-the-loop
(progress reports). Good suggestion.


With a single routine for printing, then only a few additional lines of code
would be needed, and you have covered how printing works for all reports
again.

Anyway..moving along..., if the above visible trick don't work, then placing
your doEvents right after the report open (or print) should solve this as
you mention. (am in favor of right after the open reprot).

Also, if you have *ANY* forms with a timer event, the use of doCmd.Printout
can fail unless you place a command to re-set the focus *right* before you
use the PrintOut.

DoCmd.SelectObject acReport, strRep
Thanks. I only have 1 that fires every 24-hrs. However, when it DOES
fire, it consumes a few seconds. Although the numbers are in my favor,
will take your advice - good insurance.


Anyway, at the end of the day, I am not a whole lot surprised that in one
case where you wait for windows to "render" and display the report on the
user interface screen behaves differently then another case in which you
don't display the report at all to the screen.

The display and graphics and rendering systems of windows is a highly
complex system and likely not even one single developer knows how all that
display + rendering stuff functions. Introducing the rendering system of
windows into this equation, you're certainly introducing a very large and
complex system of the whole windows operating system into the formula here.
You're right. It went right by me. I get lost in the tiny world of the
database and forget ALL about the system stuff - that can kill you
too.

.

Relevant Pages

  • Re: Data on fom not displaying
    ... Forms are not designed for printing. ... You can't control the printout ... will print the appropriate report. ... It is set to display Always, ...
    (microsoft.public.access.forms)
  • Re: printing contents of DataGridView
    ... report possibly by manually rendering the text using a graphics object. ... my printing needs are very basic and need not involve the display ...
    (microsoft.public.dotnet.framework.windowsforms.controls)
  • RE: Printing from ASP.NET application
    ... when performing printing on ASP.NET web page,correct? ... server-side .NET code that deal with printer will only affect the server ... Microsoft MSDN Online Support Lead ... I don't want the end user to have to view the report and then select the ...
    (microsoft.public.vsnet.general)
  • Re: Printouts NOT coming out in order they are sent???
    ... You using two COMPLETE different approaches to printing the repots. ... tell access to print the report, BUT DO NOT display it.. ... The display and graphics and rendering systems of windows is a highly ...
    (comp.databases.ms-access)
  • Re: How to display project date on report
    ... I'm printing the GANTT chart view. ... "Rod Gill" wrote: ... > What View or Report are you printing? ... >>> The message was checked by ESET Smart Security. ...
    (microsoft.public.project)