Running twain as service is a bit tricky, and i don’t think all twain devices are good candidates for that setup – this may be one of the reasons that you current isn’t offered as a service.
From the twain spec, twain_32.dll wants a handle to the window calling the dll, and a lot of the requirements for setting up and controling a device via twain has to do with modifying the applications message pump to communicate with twain. the kicker is that windows services don’t by default have a message pump, essage pumps are more typically found in applications that windows.
Running twain as a service is an odd contradiction, running an app to access twain (which requires something typically associated with a window) in an enviroment not really setup to have a window running. Don’t get me wrong, it can be done, but its just going to be a bit odd. My solution was to have the service create a window (that isn’t shown) and using that window’s message pump to communicate with twain.
Then there is a problem with some devices wanting to put up a messagebox, to inform the user that something went wrong. Some devices, when they put up that messagebox, don’t process anything more until the OK button is clicked. They don’t even give the application a return code or condition code that something is wrong, until that messagebox’s OK button is clicked. This too, can be somewhat avoided if you understand the device – or are just dead sure that the device doesn’t put up any messageboxes. I’ve emailed HP to see of that scanner ever puts but messageboxes, and I’ll post their reply if and when i recieve it.
Hope that in some way provides a bit of the advise you’re looking for.
gabe