Hi,

I am using COM interop to invoke MS word from my .net app. If word pops up a
dialog box, my thread obviously hangs until the dialog is answered.

Here's the problem: because the app is running on a server, there is nobody
there to answer the dialog, so I have another thread that calls Abort() on
the first thread in the event that the operation doesn't complete within a
certain amount of time.

Unfortunately, whilst the call to Thread.Abort() works, the dialog box stays
up and the subsequent Thread.Join() hangs until the dialog is cancelled.

Is there any way round this behaviour? This isn't going to happen very often
so I don't care how inefficient it is, but it's got to run on an unattended
server so I can't afford to have my app get stuck forever.

TIA

Andy

The abort does not actually get delivered to the managed thread until it
returns from the unmanaged call. There is no way to get around that
behavior.

You could try running the interop call in a separate appdomain, and then
unload the appdomain instead of using an abort. I've observed that the CLR
will go to greater lengths to unload frozen threads when unloading an
appdomain then when you simply call abort.

Another option is to run it in a totally separate process and then unload
the process. You could use remoting between processes to send data
back-and-forth between the main process and the helper process.

In short, there is no good way to shutdown a thread frozen in an unmanaged
call.



"Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
news:uIh4wV6$EHA.2552@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hi,
>
> I am using COM interop to invoke MS word from my .net app. If word pops up
> a dialog box, my thread obviously hangs until the dialog is answered.
>
> Here's the problem: because the app is running on a server, there is
> nobody there to answer the dialog, so I have another thread that calls
> Abort() on the first thread in the event that the operation doesn't
> complete within a certain amount of time.
>
> Unfortunately, whilst the call to Thread.Abort() works, the dialog box
> stays up and the subsequent Thread.Join() hangs until the dialog is
> cancelled.
>
> Is there any way round this behaviour? This isn't going to happen very
> often so I don't care how inefficient it is, but it's got to run on an
> unattended server so I can't afford to have my app get stuck forever.
>
> TIA
>
> Andy
>
>[/color]

A user dialog on a server indicates either poor design or usage of a
component outside of its intended environment. Which of the two can you
repair?

--
Regards,
Alvin Bruney

Shameless Author plug
The Microsoft Office Web Components Black Book with .NET
http://tinyurl.com/27cok


"Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
news:uIh4wV6$EHA.2552@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hi,
>
> I am using COM interop to invoke MS word from my .net app. If word pops up
> a dialog box, my thread obviously hangs until the dialog is answered.
>
> Here's the problem: because the app is running on a server, there is
> nobody there to answer the dialog, so I have another thread that calls
> Abort() on the first thread in the event that the operation doesn't
> complete within a certain amount of time.
>
> Unfortunately, whilst the call to Thread.Abort() works, the dialog box
> stays up and the subsequent Thread.Join() hangs until the dialog is
> cancelled.
>
> Is there any way round this behaviour? This isn't going to happen very
> often so I don't care how inefficient it is, but it's got to run on an
> unattended server so I can't afford to have my app get stuck forever.
>
> TIA
>
> Andy
>
>[/color]

If your service runs without "desktop interaction" enabled, it's impossible
to get around this issue. If your service runs with desktop interaction
enabled (it shouldn't) you can try to simulate Keyboard input using
SendInput (you have to make sure the dialog got focus), or you can try to
get the Window handle of the Dialog and use SendMessage to simulate a
key-press. The problem of course is "what dialog is there actually
displayed?", you won't press OK on any possible dialog don't you?

This is one of the many reasons you shouldn't try to automate "Office
applications" (or any other interactive application) on a server.

Willy.

"Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
news:uIh4wV6$EHA.2552@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hi,
>
> I am using COM interop to invoke MS word from my .net app. If word pops up
> a dialog box, my thread obviously hangs until the dialog is answered.
>
> Here's the problem: because the app is running on a server, there is
> nobody there to answer the dialog, so I have another thread that calls
> Abort() on the first thread in the event that the operation doesn't
> complete within a certain amount of time.
>
> Unfortunately, whilst the call to Thread.Abort() works, the dialog box
> stays up and the subsequent Thread.Join() hangs until the dialog is
> cancelled.
>
> Is there any way round this behaviour? This isn't going to happen very
> often so I don't care how inefficient it is, but it's got to run on an
> unattended server so I can't afford to have my app get stuck forever.
>
> TIA
>
> Andy
>
>[/color]

"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:OTqjw66$EHA.3376@TK2MSFTNGP12.phx.gbl...[color=blue]
>A user dialog on a server indicates either poor design or usage of a
>component outside of its intended environment. Which of the two can you
>repair?
>[/color]

I think it's the latter, but I don't see any other option.

I'm trying to convert a word format document to WordProcessingML. In this
case the user has uploaded a document with a password and word is asking for
the password.

AFAIK there is no other way of converting a .doc to XML other than using
winword.exe. This is the real problem - MS are pushing WordProcessingML as a
way of processing word documents on the server but it does not offer any
server-side solution to convert to and from .doc format.

From what I can see there is no way to detect if the doc is
password-protected without opening it, and no way to stop word putting up
the dialog.

any other more "out-of-the-box" suggestions would be welcome

Andy
[color=blue]
> --
> Regards,
> Alvin Bruney
>
> Shameless Author plug
> The Microsoft Office Web Components Black Book with .NET
> http://tinyurl.com/27cok
>
>
> "Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
> news:uIh4wV6$EHA.2552@TK2MSFTNGP09.phx.gbl...[color=green]
>> Hi,
>>
>> I am using COM interop to invoke MS word from my .net app. If word pops
>> up a dialog box, my thread obviously hangs until the dialog is answered.
>>
>> Here's the problem: because the app is running on a server, there is
>> nobody there to answer the dialog, so I have another thread that calls
>> Abort() on the first thread in the event that the operation doesn't
>> complete within a certain amount of time.
>>
>> Unfortunately, whilst the call to Thread.Abort() works, the dialog box
>> stays up and the subsequent Thread.Join() hangs until the dialog is
>> cancelled.
>>
>> Is there any way round this behaviour? This isn't going to happen very
>> often so I don't care how inefficient it is, but it's got to run on an
>> unattended server so I can't afford to have my app get stuck forever.
>>
>> TIA
>>
>> Andy
>>
>>[/color]
>
>[/color]

In essence what you are witnessing is one of the reasons why they warn you that Office is not suitable for server side use (theres lots of other reasons too like threading throughput). IIRC correctly, the WordML schema has now been published and generating WordML would be a more scaleable and robust solution than trying to automate word on the server

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

The abort does not actually get delivered to the managed thread until it
returns from the unmanaged call. There is no way to get around that
behavior.

You could try running the interop call in a separate appdomain, and then
unload the appdomain instead of using an abort. I've observed that the CLR
will go to greater lengths to unload frozen threads when unloading an
appdomain then when you simply call abort.

Another option is to run it in a totally separate process and then unload
the process. You could use remoting between processes to send data
back-and-forth between the main process and the helper process.

In short, there is no good way to shutdown a thread frozen in an unmanaged
call.



"Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
news:uIh4wV6$EHA.2552@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hi,
>
> I am using COM interop to invoke MS word from my .net app. If word pops up
> a dialog box, my thread obviously hangs until the dialog is answered.
>
> Here's the problem: because the app is running on a server, there is
> nobody there to answer the dialog, so I have another thread that calls
> Abort() on the first thread in the event that the operation doesn't
> complete within a certain amount of time.
>
> Unfortunately, whilst the call to Thread.Abort() works, the dialog box
> stays up and the subsequent Thread.Join() hangs until the dialog is
> cancelled.
>
> Is there any way round this behaviour? This isn't going to happen very
> often so I don't care how inefficient it is, but it's got to run on an
> unattended server so I can't afford to have my app get stuck forever.
>
> TIA
>
> Andy
>
>[/color]



--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005



[microsoft.public.dotnet.languages.csharp]

Thanks Richard, you understand my problem exactly !!

My application makes extensive use of WordML, and is a model of exactly the
type of thing MS want people to use WordML for. Unfortunately, when the user
uploads a document, I need to convert it from .doc format to WordML so get
the process started. Microsoft doesn't seem to have thought of this part of
it, so the only option open to me is to automate Word.


"Richard Blewett [DevelopMentor]" <richardb@NOSPAMdevelop.com> wrote in
message news:epOBHc7$EHA.1904@TK2MSFTNGP14.phx.gbl...[color=blue]
> In essence what you are witnessing is one of the reasons why they warn you
> that Office is not suitable for server side use (theres lots of other
> reasons too like threading throughput). IIRC correctly, the WordML schema
> has now been published and generating WordML would be a more scaleable and
> robust solution than trying to automate word on the server
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://www.dotnetconsult.co.uk/weblog
> http://www.dotnetconsult.co.uk
>
> The abort does not actually get delivered to the managed thread until it
> returns from the unmanaged call. There is no way to get around that
> behavior.
>
> You could try running the interop call in a separate appdomain, and then
> unload the appdomain instead of using an abort. I've observed that the CLR
> will go to greater lengths to unload frozen threads when unloading an
> appdomain then when you simply call abort.
>
> Another option is to run it in a totally separate process and then unload
> the process. You could use remoting between processes to send data
> back-and-forth between the main process and the helper process.
>
> In short, there is no good way to shutdown a thread frozen in an unmanaged
> call.
>
>
>
> "Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
> news:uIh4wV6$EHA.2552@TK2MSFTNGP09.phx.gbl...[color=green]
> > Hi,
> >
> > I am using COM interop to invoke MS word from my .net app. If word pops
> > up
> > a dialog box, my thread obviously hangs until the dialog is answered.
> >
> > Here's the problem: because the app is running on a server, there is
> > nobody there to answer the dialog, so I have another thread that calls
> > Abort() on the first thread in the event that the operation doesn't
> > complete within a certain amount of time.
> >
> > Unfortunately, whilst the call to Thread.Abort() works, the dialog box
> > stays up and the subsequent Thread.Join() hangs until the dialog is
> > cancelled.
> >
> > Is there any way round this behaviour? This isn't going to happen very
> > often so I don't care how inefficient it is, but it's got to run on an
> > unattended server so I can't afford to have my app get stuck forever.
> >
> > TIA
> >
> > Andy
> >
> >[/color]
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005
>
>
>
> [microsoft.public.dotnet.languages.csharp][/color]

Hmmm - you are in a bad place basically. Can you get the user to upload in WordML format in the first place? Assuming they do it via http, maybe you could check the content type of the PUT and if it is not text/xml return an error to them so they know what they have done wrong

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Thanks Richard, you understand my problem exactly !!

My application makes extensive use of WordML, and is a model of exactly the
type of thing MS want people to use WordML for. Unfortunately, when the user
uploads a document, I need to convert it from .doc format to WordML so get
the process started. Microsoft doesn't seem to have thought of this part of
it, so the only option open to me is to automate Word.


"Richard Blewett [DevelopMentor]" <richardb@NOSPAMdevelop.com> wrote in
message news:epOBHc7$EHA.1904@TK2MSFTNGP14.phx.gbl...[color=blue]
> In essence what you are witnessing is one of the reasons why they warn you
> that Office is not suitable for server side use (theres lots of other
> reasons too like threading throughput). IIRC correctly, the WordML schema
> has now been published and generating WordML would be a more scaleable and
> robust solution than trying to automate word on the server
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://www.dotnetconsult.co.uk/weblog
> http://www.dotnetconsult.co.uk[/color]

Unfortunately that's not an option from a business perspective. we'll have
to have some kind of solution even if it comes down to a robot arm which
presses the escape key every 20 seconds ;-))

current options I'm looking at are (a) using SendKeys; or (b) killing every
copy of winword.exe on the machine. Not what you'd call elegant

Andy



"Richard Blewett [DevelopMentor]" <richardb@NOSPAMdevelop.com> wrote in
message news:ubw7NV8$EHA.2540@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hmmm - you are in a bad place basically. Can you get the user to upload in
> WordML format in the first place? Assuming they do it via http, maybe you
> could check the content type of the PUT and if it is not text/xml return
> an error to them so they know what they have done wrong
>
> Regards
>
> Richard Blewett - DevelopMentor
> http://www.dotnetconsult.co.uk/weblog
> http://www.dotnetconsult.co.uk
>
> Thanks Richard, you understand my problem exactly !!
>
> My application makes extensive use of WordML, and is a model of exactly
> the
> type of thing MS want people to use WordML for. Unfortunately, when the
> user
> uploads a document, I need to convert it from .doc format to WordML so get
> the process started. Microsoft doesn't seem to have thought of this part
> of
> it, so the only option open to me is to automate Word.
>
>
> "Richard Blewett [DevelopMentor]" <richardb@NOSPAMdevelop.com> wrote in
> message news:epOBHc7$EHA.1904@TK2MSFTNGP14.phx.gbl...[color=green]
> > In essence what you are witnessing is one of the reasons why they warn
> > you
> > that Office is not suitable for server side use (theres lots of other
> > reasons too like threading throughput). IIRC correctly, the WordML
> > schema
> > has now been published and generating WordML would be a more scaleable
> > and
> > robust solution than trying to automate word on the server
> >
> > Regards
> >
> > Richard Blewett - DevelopMentor
> > http://www.dotnetconsult.co.uk/weblog
> > http://www.dotnetconsult.co.uk[/color]
>[/color]

"Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
news:OGw$th8$EHA.1408@TK2MSFTNGP10.phx.gbl...[color=blue]
> Unfortunately that's not an option from a business perspective. we'll have
> to have some kind of solution even if it comes down to a robot arm which
> presses the escape key every 20 seconds ;-))
>
> current options I'm looking at are (a) using SendKeys; or (b) killing
> every copy of winword.exe on the machine. Not what you'd call elegant
>
> Andy[/color]

Did you look for alternatives that don't require Word at all?
Following a just a few I have used for asp based applications, guess they
offer the same for asp.net too.

http://www.polarsoftware.com/product...rter/index.asp

http://officewriter.softartisans.com...riter-253.aspx

Willy.

"Willy Denoyette [MVP]" <willy.denoyette@pandora.be> wrote in message
news:urZ6D68$EHA.3120@TK2MSFTNGP12.phx.gbl...[color=blue]
>
> "Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
> news:OGw$th8$EHA.1408@TK2MSFTNGP10.phx.gbl...[color=green]
>> Unfortunately that's not an option from a business perspective. we'll
>> have to have some kind of solution even if it comes down to a robot arm
>> which presses the escape key every 20 seconds ;-))
>>
>> current options I'm looking at are (a) using SendKeys; or (b) killing
>> every copy of winword.exe on the machine. Not what you'd call elegant
>>
>> Andy[/color]
>
> Did you look for alternatives that don't require Word at all?
> Following a just a few I have used for asp based applications, guess they
> offer the same for asp.net too.
>
> http://www.polarsoftware.com/product...rter/index.asp
>
> http://officewriter.softartisans.com...riter-253.aspx
>
> Willy.
>[/color]

Thanks, Willy, I was aware of Aspose but not sure if that supports WordML
yet. I'll take a look at these other two.

The comments about dealing with Word.Exe (a nearly 12MB executable!) as a
COM Server are on the money.
Several vendors (one to look at is "Aspose") have 100% managed code class
libraries that can talk "word", "Excel" and so on.

They aren't cheap, but you won't be left with 123 instances of WORD.EXE in
Task Manager...

Good luck!

"Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
news:uIh4wV6$EHA.2552@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hi,
>
> I am using COM interop to invoke MS word from my .net app. If word pops up[/color]
a[color=blue]
> dialog box, my thread obviously hangs until the dialog is answered.
>
> Here's the problem: because the app is running on a server, there is[/color]
nobody[color=blue]
> there to answer the dialog, so I have another thread that calls Abort() on
> the first thread in the event that the operation doesn't complete within a
> certain amount of time.
>
> Unfortunately, whilst the call to Thread.Abort() works, the dialog box[/color]
stays[color=blue]
> up and the subsequent Thread.Join() hangs until the dialog is cancelled.
>
> Is there any way round this behaviour? This isn't going to happen very[/color]
often[color=blue]
> so I don't care how inefficient it is, but it's got to run on an[/color]
unattended[color=blue]
> server so I can't afford to have my app get stuck forever.
>
> TIA
>
> Andy
>
>[/color]

I've looked at aspose but unfortunately they don't support WordML yet.

there is something called PolarConverver which purports to do exactly what I
want, but unfortunately there are too many of my test documents it barfed
on.

"Peter Bromberg [MVP]" <pbromberg@yahoo.com> wrote in message
news:OHMhXNAAFHA.3836@tk2msftngp13.phx.gbl...[color=blue]
> The comments about dealing with Word.Exe (a nearly 12MB executable!) as a
> COM Server are on the money.
> Several vendors (one to look at is "Aspose") have 100% managed code class
> libraries that can talk "word", "Excel" and so on.
>
> They aren't cheap, but you won't be left with 123 instances of WORD.EXE in
> Task Manager...
>
> Good luck!
>
> "Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
> news:uIh4wV6$EHA.2552@TK2MSFTNGP09.phx.gbl...[color=green]
>> Hi,
>>
>> I am using COM interop to invoke MS word from my .net app. If word pops
>> up[/color]
> a[color=green]
>> dialog box, my thread obviously hangs until the dialog is answered.
>>
>> Here's the problem: because the app is running on a server, there is[/color]
> nobody[color=green]
>> there to answer the dialog, so I have another thread that calls Abort()
>> on
>> the first thread in the event that the operation doesn't complete within
>> a
>> certain amount of time.
>>
>> Unfortunately, whilst the call to Thread.Abort() works, the dialog box[/color]
> stays[color=green]
>> up and the subsequent Thread.Join() hangs until the dialog is cancelled.
>>
>> Is there any way round this behaviour? This isn't going to happen very[/color]
> often[color=green]
>> so I don't care how inefficient it is, but it's got to run on an[/color]
> unattended[color=green]
>> server so I can't afford to have my app get stuck forever.
>>
>> TIA
>>
>> Andy
>>
>>[/color]
>
>[/color]

FWIW here was my solution:

1. find the process ID of the winword.exe you are using. This is not easy
with COM so the only way I could think of is to enumerate all winword.exe
processes just before creating the COM object and then again afterwards.
Compare the two lists and new one is the OOP server you're connected to

2. afer calling thread.abort(), if thread.join() doesn't return in a few
seconds, kill the winword.exe process and call thread.join() again

it's not elegant but it works for me.

"Andy Fish" <ajfish@blueyonder.co.uk> wrote in message
news:uIh4wV6$EHA.2552@TK2MSFTNGP09.phx.gbl...[color=blue]
> Hi,
>
> I am using COM interop to invoke MS word from my .net app. If word pops up
> a dialog box, my thread obviously hangs until the dialog is answered.
>
> Here's the problem: because the app is running on a server, there is
> nobody there to answer the dialog, so I have another thread that calls
> Abort() on the first thread in the event that the operation doesn't
> complete within a certain amount of time.
>
> Unfortunately, whilst the call to Thread.Abort() works, the dialog box
> stays up and the subsequent Thread.Join() hangs until the dialog is
> cancelled.
>
> Is there any way round this behaviour? This isn't going to happen very
> often so I don't care how inefficient it is, but it's got to run on an
> unattended server so I can't afford to have my app get stuck forever.
>
> TIA
>
> Andy
>
>[/color]