I'm testing software that sends jobs to the printer queue and then rises a flag when they are successfully printed. It also needs to detect how many pages printed correctly in a failed job.
Although there are many "Virtual Printers" out there, they all process their jobs perfectly... And that's the problem.
Is there a printer simulator that can provide with control over the signals it sends back to the windows spooler, such as printed pages, out of paper errors, paper jams, etc?
I'm not interested in the raw output the printer driver handles to the printer, but rather the signals the driver passes back to the windows' spooler.
Related
I am writing some software that tries to print via IPP to typical HP laser printers like the M605, for example, and it is having a hard time "waking up" the printer sometimes. What happens is that the software tries to connect to the printer's IP address on the local network (10.1.10.185 or whatever) and gets a "No route to host" error. If the user tries several times in a row, eventually the printer "wakes up" and begins responding.
I notice that regular Linux or Window programs that print to the printer do not seem to have this problem. So, either they are not using IP/networked printing or they have some way to deal with the "sleeping" problem that I am not aware of. I suppose I could put a tap on the ethernet cord, and print from a Windows program and see what it is doing, but that would be a very time consuming and laborious procedure.
Does anybody know what I am doing wrong here? Is there some way to wake up a printer via its internet connectivity access protocol?
One thing I noticed in one person's code is that they had a 30-second timeout specified on the connect, so that may be the issue, is that my connection timeout is just not what it should be. In that case, is there an established timeout period for waking up HP printers?
I an bringing up my home print server using RaspberryPi+CUPs
MY printer is HP Laserjet MTF m1212nf.
Apprently, I I was able to setup everything good enough to be able sending jobs over the network and get them printed.
However, one problem i am running into is that once I leave the printer Idle for some time, it seems to go into kinda standby mode (kinda power-saving mode) and then jobs i send show as completed in the CUPs interface, but they never get to be printed on paper.
From this point, the way to resume printing is to shut off and then on the printer and then things work again until next go into power saving mode.
What you look for is Tea4Cups, which is a bridge beetween commands and cups.
For installation on RPi see here: (step 1-3) https://github.com/Felixel42/Printer-Pi-DCP-115C#tea4cups
Prefix your printer line i.e. smb://yourprinter so that it looks like that
tea4cups:/smb://yourprinter
The configuration file is at /etc/cups/tea4cups.conf
A minimal example is
[global]
directory : /var/spool/cups/ #you might need to adjust this
prehook_0 : wakeonlan yourmac #or whatever command you want to execute
I recently purchased an HP Deskjet wifi-enabled printer (model no. 3515). Set it up successfully as good as that both me (in the same network as the printer) as well as another person few miles apart from me (having different isp than mine) could print wirelessly successfully.
The printing across network (printing from a network other than that to which the printer is connected) has been set-up and tested successfully both through Google Cloud Print and HP ePrint Software.
However, when it comes to scanning across network, or cloud scan as we may call it, none of these two support, or even say anything about, it. Talking to an HP customer care executive about it was fruitless as i expectedly got no better answer than 'it is not possible'. Also, unfortunately, I have not found anything worthwhile on internet regarding this either.
What my understand is - if printing could be done wirelessly across network, so could be scanning. After all, in both we do roughly the same thing but in opposite direction. That is, in layman's terms, if i am not wrong, in printing we convert digital information into hardcopy document, and in scanning it is just the other way round.
Please correct me if am assuming too many things too wrong.
HP ePrint is email based, i.e. the printer acts as an email client that polls a mailbox for print jobs. When you print to the cloud, your printjob goes to your printer's mailbox and the printer fetches the job from there. It is pretty much one-way, in the sense that you just send off the print job and hope it gets printed and there can be many different clients submitting print jobs to the same printer.
Scanning is much more complex and actually requires a fully working two-way communication, i.e. the computer is interacting with the scanner to tell it do to do a preview scan, selecting scannable areas/size, setting resolutions, etc. while getting instantaneous responses and data from the scanner. So it is not really feasible to do via a mailbox, and at least not via the printer's mailbox as you cannot read results from its mailbox.
You would think it would be possible for the scanner to send scanned pages to your mailbox, but I guess the implementation is just not there yet. There are some security implications, such as it would be a bad idea to start a scan job from a remote location, because then any bad guy could try to scan whatever secret document you happen to have placed in the scanner. But if you were to initiate the scan from the scanner and there select the email address to send the results to, it should be secure enough. I guess the developers at HP are saving some features for the next generation of multi-purpose devices so they can sell you a new device next year.. :)
We have some computers on which we charge for printing documents. When a user prints, I would like to intercept the print job, prompt them for their username / password so I can charge their account, then allow the print job to continue through to the printer.
How can this be accomplished? Is it possible to write such a utility in .NET?
You really need to look at creating a Port Monitor for this. Far from simple. You could look at RedMon. BTW: Many printer vendors offer solutions to this which use codes that are embedded into the print stream (PCL/PS) and the data is collected and retained on the printer.
For example, Xerox has something called Standard Accounting. When enabled in the driver it embeds PJL codes like this:
#PJL COMMENT OID_ATT_ACCOUNTING_INFORMATION_AVP "XRX_USERID,xxxx";
Once the job has been printed the device makes reference to the user, number of pages etc. which can then be reported on.
The problem you will run into when doing this on the workstation / server is that detecting the number of pages printed can be difficult. If you are trying, for example, to charge by the page you might be able to parse the number of pages from the file, or run through a PCL or PS RIP and determine but if they have a flag for 2up or 4up on the page and that work is done by the printer and not the driver, you will charge the client for 4 pages when they really only printed 1. That is one of the many pitfalls.
I have created a windows service that uses Windows Messaging System. When I test the app from the debugger the Messages go through nicely but when I install it my messag … asked 14 mins ago
vladimir
1tuga
Services don't generally receive window messages. They don't necessarily have window handles at all. Even if they do, they run in a separate desktop. Programs cannot send messages from one desktop to another, so a service can only receive messages from another service, or from a program started by a service.
Before Windows Vista, you could have configured your service to interact with the desktop. That makes the service run on the same desktop as a logged-in user, so a program running as that user could send messages to your service's windows. Windows Vista isolates services, though; they can't interact with any user's desktop anymore.
There are many other ways to communicate with services. They include named pipes, mailslots, memory-mapped files, semaphores, events, and sockets.
With a socket, for instance, your service could listen on an open port, and programs that need to communicate with it could connect to that port. This could open the door to remote administration, but you can also restrict the service to listen only for local connections.
All the above is trying to tell you that you're taking the wrong approach. But there's also the matter of the problem at hand. Your program behaves one way in the debugger and another way outside it. How are you debugging the service in the first place, if it's not installed? What user account is your service running as? Your debugger? What debugging techniques have you tried that don't involve the debugger (e.g. writeln to a log file to track your program's actions)?
What do you mean when you say it "uses" Windows Messaging System? Are you consuming or sending Windows Messages?
If you send a Windows message, you need ensure you are doing it correctly. I'd suggest writing a message loop to ensure your messages are being dispatched properly. I'd also suggest reading up on message loops and how they work.
What is a Message Loop (click the title to be taken to the source of this info)
while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
The message loop calls GetMessage(),
which looks in your message queue.
If the message queue is empty your
program basically stops and waits
for one (it Blocks).
When an event occures causing a
message to be added to the queue
(for example the system registers a
mouse click) GetMessages() returns a
positive value indicating there is a
message to be processed, and that it
has filled in the members of the MSG
structure we passed it. It returns 0
if it hits WM_QUIT, and a negative
value if an error occured.
We take the message (in the Msg
variable) and pass it to
TranslateMessage(), this does a bit
of additional processing,
translating virtual key messages
into character messages. This step
is actually optional, but certain
things won't work if it's not there.
Once that's done we pass the message
to DispatchMessage(). What
DispatchMessage() does is take the
message, checks which window it is
for and then looks up the Window
Procedure for the window. It then
calls that procedure, sending as
parameters the handle of the window,
the message, and wParam and lParam.
In your window procedure you check
the message and it's parameters, and
do whatever you want with them! If
you aren't handling the specific
message, you almost always call
DefWindowProc() which will perform
the default actions for you (which
often means it does nothing).
Once you have finished processing
the message, your windows procedure
returns, DispatchMessage() returns,
and we go back to the beginning of
the loop.
Thank you all for the answers,
the issue was the operating system (vista), i tested the with my windows 2000 and everything works.
thanks for the light Rob.