Printer waits for 1 minute

[Mike Doty]

I shell from a DOS program to a PB/DLL program that
prints using Ddoc to Windows only printers. It has worked
great for a long time. Today, I got a call that a
printer will not print for about 1 minute. I've
tried everything from changing the printer properties
and printing directly to the printer using raw to
checking the properties of the DOS program looking
for suspend or something else. No matter what settings
I use on my test printer (a BJC-6000) it works fine.
The client says NOTEPAD and other Windows programs
print immediately.

Anyone know of anything else to look at? The client
was using Windows 98 with a Samsung ML 4500.




[This message has been edited by Mike Doty (edited November 09, 2000).]

[Lance Edmonds]

Mike, is the problematic printer networked or just a local printer? If your software offers conventional DOS printing as well as Windows printing via DDOC, are you 100% sure that they are not suffering from the 1 minute delay that networked DOS printing can suffer from? If so, this can be addressed with some settings in the WIN.INI file.

Since Don Dickinson's DDOC library uses the API to do it's printing, it is hard to understand how this can occur without being able to actually try the printer concerned. You are a registered DOSPRINT user, so I have to ask it DOSPRINT suffers the same problem? If so, it would be 1st instance of this problem that I've come across.

However, you should be able to install the same driver they are using to at least try to emulate their settings - your printer will probably start to print garbage as a result of using the wrong driver, but as long as you only load one page of paper at a time, you should be able to get some idea of the time it takes for the job to spool and then start printing.

Are they using some kind of "printer manager" software with their Samsung? If so, can the manager software be disabled?


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Doty]

I'm e-mailing with the client right now and it
is a Samsung ML 4500. They are networked with
4 computers, but each computer only prints to
its own printer. I'll check on the print manager software.
Thanks!
Mike


------------------


[This message has been edited by Mike Doty (edited November 09, 2000).]

[Don Dickinson]

I don't have much to add to what Lance said. The only other thing I can think of is maybe a weird printer driver. When ever someone reports a printer anomly to me, the first thing I have them do (if it's a laser printer) is install an HP 2 generic driver and print to the printer with that. I that exhibits the same problem then it's not the driver, it's a printer or network setup issue.
Best Regards,
Don

------------------

[Chris Boss]

Mike;

Just because each computer has its own printer, does not
necessarily mean they are not "spooling" through the network.

If the computers are setup to spool through the network
software, then the entire print process will likely be delayed.

When I would install networks, I would always make sure the printers
were not only local (one for each computer), but I would make sure
the network software didn't spool the data for printing.


------------------

[Bruce Singleton]

Mike this might help. I use Ddoc on both stand alone and net computers
Make sure the the Enddoc% = line contains at the end of the line
" %Ddoc_end_delete "

If this is not present you will find in the windows\temp directory
files with the ddc extension. This will greatly slow generating and
printing reports with ddoc. When I removed the ddc files from
windows\temp directory the printing routine returned to normal speed.

Bruce



------------------

[Frank Kelley]

I ran into this same problem using a DOS app through a Windows network.
The solution can be found at:
http://support.microsoft.com/support.../q140/0/36.asp

Frank

------------------

[Lance Edmonds]

Frank, DDOC uses API printing, not DOS port capturing...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Doty]

I think the problem is solved by pausing in the
DOS program after issuing a SHELL. Waiting 2
seconds after the SHELL in the DOS program
gives immediate printing all the times to
a BJC-6000 printer. Without it the printer
will sometimes wait 10 seconds.

Does this mean some programs can't allocate
properly unless the calling program pauses?
Should a wait always be performed after a SHELL?



------------------

[Lance Edmonds]

Bizarre...

Is your DDOC wrapper APP a console-subsystem app or a GUI-subsystem app?

If it is a GUI-subsystem app, then the PB/DOS SHELL statement is probably returning almost immediately, as the GUI app will have been started as a separate process.

Have you tried using my WINLINK.EXE utility to launch the DDOC wrapper app?



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Doty]

Lance,
The wrapper program is a PB/DLL program that
I've named WINPRINT.EXE. It will print any
text files and allows parameters such as
/NODIALOG /LABELS /PRINTERNAME, and many more.
The delay problem is definitely interesting!

I've never heard of WINLINK. I'd like to try it.
Thanks,
Mike


------------------

[Lance Edmonds]

Email me privately & I'll send it to you...

To use it, simply place i "into" your SHELL statement:

ie, if your original SHELL is:

SHELL "WINPRINT.EXE <params>"

then change it to:

SHELL "WINLINK.EXE WINPRINT.EXE <params>"

Final note: WINPRINT is a trademarked name - you may have a few problems with that one! That was what I initially called DOSPRINT, and was forced to change it.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]owerbasic.com</A>

[Lance Edmonds]

Mike reported to me that WINLINK does indeed fix the problem.

WINLINK works by "enforcing" synchronous SHELLing from a DOS application that launches a GUI application. Normally, a GUI app is started as a separate process from a DOS Basic SHELL statement, and this causes the DOS Basic SHELL statement to become asynchronous. Because the GUI app is a separate process, control is not brought back to the DOS application when the GUI app terminates. WINLINK solves both of these problems.

A note to the lurkers here: WINLINK.EXE is included with the registered version of DOSPRINT 1.20 www.dosprint.com or www.dllprint.com - It can also be made available FREE to programmers by special request to my private email address mailto:[email protected][email protected]</A> .

Regards,
Lance