>I'll repeat my ealier question because some people can not think for

There are actually two (2) possibilities here...

One is that you actually want to print the invoices on the printer connected
to the *WEB* *SERVER*  If that is the case, you really should skip the whole
JavaScript part, and just mess with lp and PHP from the command line, if at
all possible.

The other is that you have a little "hole" in the background knowledge you
need to understand why you're really not making a lot of sense by insisting
that PHP "pause" the dialogs...

>I want to run a print job of 200+ invoices
>I have a javascript code to open a print dialog box and
>Then go to next invoice and do the loop..
>Problem I am having is that I want it to pause if the ok button on the 
>dialog Box is not pressed..
>When I run the script it fly's throught and brings up a heap of printer
>Dialog boxes which causes me to ctrl+alt+del...
>Anyway or pausing the script untill ok is pressed?
>Thanks in advance..
>(PS: I have sent this to this group because
> 1. The loop is done in php and NOT javascript

The loop you are using in PHP is *generating* JavaScript.

The *PRINTING* is being done on the *BROWSER* and PHP lives on the *SERVER*

So the loop speed is not the controlling factor.  Honest.  More on this in a

> 2. My question is regarding php and pausing the loop and not
>with the javascript code)

You can, if you like, use http://php.net/sleep to pause that loop as much as
you want.

*BUT* this is almost for sure *NOT* going to work all by itself.

Look at this picture:

+-------------------+           +---------------------+
| Browser         1.|-- URL---->|2. Web Server        |
|                   |           |3, 4, 5.             |
| JavaScript      7.|<----------|6. PHP               |
|                 8.|           |                     |
|         9.        |           +---------------------+

Now, take this in "slow motion"

1. Browser asks for URL.
2. Web-Server gets Request.
3. Web-Server identifies it as PHP page.
4. Web-Server fires up PHP.
5. PHP spews out HTML/JavaScript response.
6. PHP finishes HTML/JavaScript output.
7. Browser gets HTML/JavaScript.
8. Browser displays HTML.
9. Browser executes JavaScript.

As you can see, it really doesn't matter how fast or how slow your PHP
script delivers the HTML/JavaScript to the browser, really.

The *JAVASCRIPT* execution determines how fast those dialogs are going to
pop up, no matter how quick/fast PHP delivers it.

Think of it this way:  Whether the pitcher throws a fast ball or a curve,
it's how hard the batter *HITS* the ball that makes it a home run or not. 
So the speed of the ball delivery is irrelevent to the distance the ball

[Technically, Newton's action/reaction laws do factor in a trifle on the
ball's speed, but let's not pick nits, okay?]

Similarly, no matter what speed PHP delivers the JavaScript, it's the Java
engine that runs it.  Don't matter if PHP delivers it slow or fast, the
*BROWSER* gonna run it the same speed.

Actually, 5, 6, 7, and 8 can "over-lap" a little.

So, really long and complicated PHP with lots of HTML going out *might* have
the browser displaying the top of the HTML before PHP finishes spewing out
the bottom of the HTML...

But, honestly, even when you *think* that's happening, it's usually really
just the browser being slow to *draw* the HTML, and PHP has finished and
gone home already.

So for all practical purposes, you might as well just think of each of those
9 steps as one after the other.  (And if you have TABLE tags, it *IS* going
to be one after the other.)

Now, you just *MIGHT* achieve a very crude control over PHP output and
convince *SOME* browsers to execute the JavaScript if you do this "just

1. You'll probably have to have all the "print" happen in the HEAD tag, or
maybe even before the HTML tag, so the browser doesn't get "distracted" by
the layout of the BODY.

2. You'll almost-for-sure have to send each "Print" job in a *SEPARATE*
<SCRIPT></SCRIPT> tag, or the JavaScript compiler will be waiting for the
closing </SCRIPT> before it compiles the JavaScript and executes it.

3. You'll need to call http://php.net/flush after each "print" is output, so
that the JavaScript is forced out to the browser.

Even, then, I'm betting this just isn't gonna work... It *might* on *some*
browsers, but not reliably...

Still, here it is:

  while (list($invoice) = each($invoices)){
    echo "<SCRIPT LANGUAGE=JavaScript>\n";
    echo javaprint($invoice); # Whatever it takes to do the "print" in
    echo "</SCRIPT>\n";

You *MIGHT* be able to get away with putting the JavaScript into the HEAD
part, but almost-for-sure if you put it into the BODY or lower, it ain't
gonna work.  I could be wrong on that part, but I doubt it.

Of course, if it's in the HEAD or higher, then while you're waiting for the
printing, the browser can't display the BODY, since it hasn't received it
yet, so you'll have a blank page the whole time you're printing.  Maybe
that's okay, though.

Meanwhile, you are *SHAMELESSLY* tying up your web-server to do a timed
loop, which JavaScript is *perfectly* capable of doing.  I think I even
posted some sample code of a JavaScript timeout recently that you can use.

Certainly, if you *INSIST* on doing this in PHP, you *MIGHT* get it to work
(or might not), but I *KNOW* you can do the timing part in JavaScript,
without tying up your web-server needlessly.

HTTP connections are a very expensive resource.  Tying one up long enough to
wait a couple seconds for the user to click "Ok" 200+ times is a Bad Idea

Deliver the HTML and JavaScript to the browser, and use the JavaScript to
"time" your print jobs.

I hope this helps better explain why everybody was saying "It's not a PHP
issue -- It's JavaScript"

PS  I also know that sitting there and clicking "Ok" 200+ times on the print
dialogs is sheer torture.  If you're only torturing yourself, go ahead, but
if it's a real user, or an employee, don't count on them doing the job

Good Luck!

Like Music?  http://l-i-e.com/artists.htm

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to