Faxing using MS Fax SDK and Windows Service w/o desktop interactio

[Guest]

I'm trying to write a Windows Service that will utilize MS Fax to
programatically send faxes. The Service must work whether or not a user is
logged in, but I'm predictably running into problems with desktop
interaction. My code has no user interface, but the "ConnectedSubmit"
function of the Extended COM Fax library causes the application associated
with the fax document to launch, print the document to the fax server, and
then shut down. Though far from ideal, this will work if the "Allow Desktop
Interaction" option is selected in the SCM and a user is logged in. But if a
user is not logged in, the Connected Submit function just hangs until someone
logs in, and then proceeds to launch the app, etc. Does anyone have any
suggestions? Is there any way to send the fax in the background without
interacting with the desktop?

Thank you very much in advance-

Chet

 

[Angus Comber]

I use the C API rather than the COM API but it works in a similar fashion -
ie the application is launched to 'print' the document. I would be very
interested if there is a way to to solve your problem - as I need to solve
this myself. My email address is (e-mail address removed) - just take out
the NOSPAM bit.

I used to use a program called Zetafax (another fax server) which also
needed to launch the application to 'print' - Zetafax can work as a service
so there must be a way round the problem.

Incidentally why not use C API?

Angus Comber
(e-mail address removed)

 

[Guest]

The MSDN documentation recommends using the Extended COM API for new
applications, and since I'm using VB.NET, it seems the most straightforward
approach.

Can anyone out there answer the original question for us?
Thanks -

 

[Raghavendra R [MSFT]]

This is (technically) by design. Take a look at
http://g.msn.com/9SE/1?http://suppo...ac74a2c855bc854&POS=2&CM=WPU&CE=2&CS=AWP&SR=2.
As mentioned in that article your services should be endlessly waiting for
windows messages & hence are hung.

But we'd like to listen to your scenarios in more detail. Can you please
explain us what your services do? May be we can redesign your client/service
architecture to circumvent this problem. As such, in my opinion a good
client-server model will not face this issue.

Angus you mentioned 'Zetafax can work as a service'. 'Windows Fax Service'
is also a service. I didn't quite understand your point. Is it possible to
send faxes from a (user-created) service using Zetafax APIs?

--
Raghavendra R
Microsoft Printing, Imaging and Fax Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.'

 

[Guest]

I'm not sure that just because I want to send a fax from a Windows Service
that I have a flawed design, hehe

Seriously though, I agree that most complex programming questions have their
root in poor design. But in this case, design is moot. I don't have a
client-server application. What would be considered the "client" in this
case is totally beyond my control. I am simply writing a application that
will reside on a server and work through a queue of fax jobs waiting in a
data store. Since it requires no user input, and ideally would run whether
or not someone is logged in, and also would ideally run in the background, a
Windows Service is the obvious choice. As you can see, design of the
application hasn't even begun when the issue at hand pops up.

The issue at hand, simply put, is this: using MS Fax SDK in a
non-interactive Windows Service is not fully supported. At least it doesn't
seem so. This is because it relies on the implementation of the PrintTo
function in whatever application happens to be associated with the doc type
you're trying to send. When you call something like ConnectedSubmit, the
flow of your program is surrendered to whoever has implemented the PrintTo.
The associated application formats the document and prints it using the fax
printer driver. MS Fax SDK does this because it's a convenient way to
convert the file to TIFF format.

The problem is that the associated app can do god-knows-what when that
PrintTo function is called. It could be asking the non-existent user to play
a game of chess for all MS Fax knows. That's what I call poor architecture.

My headache lies in MS Word's implementation of PrintTo, because it
unnecessarily pops the app before printing it. That would be fine if it
didn't hang itself when the OS won't paint the window.

There are a lot of options for workarounds here, but make no mistake,
workarounds are what they will be. I'm pretty confident at this point that
there is no straight resolution. For myself, I'm going to restrict document
types to PDFs for now. I've discovered that Acrobat Reader will pop if
desktop interaction is enabled, otherwise it continues as expected without
hanging.

Any further input is appreciated, thanks -
Chet

 

[Raghavendra R [MSFT]]

Hi Chet,
We did the test ourselves in-house & found that the problem lies with .doc
files as you observed. We could successfully send documents of type .bmp,
..txt., .pdf. So I think we should rather follow-up in Microsoft Word
Newsgroup & see if we can get any useful insights. We'll get back to you in
case we have more information about the same.

Coming to your comment on poor architecture - the problem you mentioned
exists in most of frameworks that are extensible. Put in simple terms - take
any framework or design that's extensible, meaning 3rd party developers or
ISVs (or whatever you call them as) can provide hooks. In the most simple
form this hook will be in the form of a callback to be provided by a DLL
supplied by the 3rd party developer. The core framework calls the hook
(function) provided by 3rd party developer. This function can do anything,
it can even call ExitProcess. This doesn't imply a poor architecture. Many
designs try to minimize what 3rd parties can do to them by probably hosting
3rd party DLLs in a separate process, by calling them & giving up after
certain amount of time etc. But I'd think an extensible design is always
tough to be completely protected against such attacks.

In our case we have to call the associated application to tell us about its
format because only it knows the format. PrintTo happens to be the way to do
this in the current design. In any design, given that the application has to
be called, it has the freedom to do anything - to not return (hang).

--
Raghavendra R
Microsoft Printing, Imaging and Fax Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.'