Re: Faxing using MS Fax SDK and Windows Service w/o desktop intera

From: Raghavendra R [MSFT] (raghavr_at_online.microsoft.com)
Date: 12/22/04


Date: Wed, 22 Dec 2004 16:27:16 +0530

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.'
"Chet" <Chet@discussions.microsoft.com> wrote in message 
news:8665FA67-553C-4B98-A362-18334C5D969B@microsoft.com...
> 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]" wrote:
>
>> This is (technically) by design. Take a look at
>> http://g.msn.com/9SE/1?http://support.microsoft.com/default.aspx?scid=kb%3BEN-US%3Bq171890&&DI=4029&IG=7faedd31f51846c1aac74a2c855bc854&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.'
>>
>> "Chet" <Chet@discussions.microsoft.com> wrote in message
>> news:5BE2D0F6-AFDE-4E69-B734-372688A970F0@microsoft.com...
>> > 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 -
>> >
>> >
>> > "Angus Comber" wrote:
>> >
>> >> 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 fax@NOSPAMiteloffice.com - 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
>> >> angus@NOSPAMiteloffice.com
>> >>
>> >>
>> >>
>> >> "Chet" <Chet@discussions.microsoft.com> wrote in message
>> >> news:02428779-3C16-4015-9D7C-A44FE51A87C2@microsoft.com...
>> >> > 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
>> >> >
>> >>
>> >>
>> >>
>>
>>
>> 


Relevant Pages

  • Re: Faxing using MS Fax SDK and Windows Service w/o desktop intera
    ... I'm not sure that just because I want to send a fax from a Windows Service ... root in poor design. ... This is because it relies on the implementation of the PrintTo ... > client-server model will not face this issue. ...
    (microsoft.public.win2000.fax)
  • Re: Excel Workbook creation using C#
    ... Why do you say it is by design? ... >>> Prisy ... >> Is this a windows or console application, or is it a Service style ... (Windows Service, Web application). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How to host web service methods in your windows application?
    ... I am also facing a similar design issue. ... Clients using TIBCO Messages.Its a two way interaction.The Client sends ... Writing a Remoting Class within this Windows Service which will expose ... This WebService Method will invoke this Remoting Class Method and sent ...
    (microsoft.public.dotnet.framework.clr)
  • Invoking an unmanaged exe
    ... I am just beginning to explore this area, so my question may seem ignorant. ... I am trying to design a Windows service in VB.NET that would grab a file and ... How do I invoke Procomm Plus with my windows service and pass it my ...
    (microsoft.public.dotnet.framework.interop)
  • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
    ... Usually a public API ... I regard this as fairly poor design for library API's. ... details to a lower level subsystem and wait for a response with the ... Apple were major clients back in the '80s but that business moved to ...
    (comp.object)

Loading