Word automation problem

I am developing a VB application which has to select word files from a directory and its subdirectories, add certain content and save it. This application has to run as batch without any user intervention. the app encounters problem while opening certain files as it throws alerts/message windows like "file is locked for editing by another user...." or "the document caused serious error the last time it was opened..."

the application halts there.

How do i get around this problem.. i tried out setting

wrdapp.AutomationSecurity = msoAutomationSecurityForceDisable
wrdapp.displayalerts=wdAlertsNone

but of no use..  anyone can u help me
LVL 1
myvinodAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

twalgraveCommented:
If the file is locked, there's NOTHING you can do about it.  However, the program doesn't have to stop.  You can simply set error handling to bypass that:

on error resume next ' skips to the next line

or

on error resume MyLabel ' jumps to a label in the current procedure named MyLabel

or

on error goto 0 'turns off error handling

best practice is to use on error resume next, then check the error number
for example:

on error resume next

error 13
if err.number = 13 then
   err.clear
   exit sub
endif

These are just examples, use them in your program as you see fit.
0
myvinodAuthor Commented:
resuming on error will happen when the control is returned back to the program. Here the control is still with the word application which is currently showing the alert. this is the code i have used.. i have even used on error stmt.. without any result
this is the code i have used for opening the word document
:
:
Set owrdDocument = owrdApplication.Documents.Open(strFName)
:
:
0
myvinodAuthor Commented:
resuming on error will happen when the control is returned back to the program. Here the control is still with the word application which is currently showing the alert. this is the code i have used.. i have even used on error stmt.. without any result
this is the code i have used for opening the word document
:
:
Set owrdDocument = owrdApplication.Documents.Open(strFName)
:
:
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

dmangCommented:
when the error occurs, try Sendkeys to send enter .. that is ... OK, make a copy of the file for display.

At this point you can try a couple of things..

1.  insert your updates and save as a different file name
   
2.  generate a message on an error log that the file was locked for edit by another user, and that it need to be processed again, and close the file without saving.

0
myvinodAuthor Commented:
"sendkeys" can be sent when control returns to the VB application. the problem here is the control is never returning back to my application neither are any errors thrown.

newly i have tried out on App.OleServerBusyRaiseError metthod in my VB application, even this is not working. Although the other App.ole<properties> are working.
0
twalgraveCommented:
I don't know why you are not receiving the error in your app, but I suspect it is because it is being handled by the other app.  Either way, one of the common techniques is along the lines of what dmang was saying.  However, it is implemented by first setting off a timer or another thread.  The timer/thread will sit in a loop doing a findwindow until it either finds the error popup window or your code sets a flag indicating the success of the operation.  If it finds the window, it sends the enter key.  If your native code returns, this means the error did not happen, so set a flag and check for that as well in the timer loop.  If this doesn't make sense, I can giv eyou a link on how to do it.


0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
myvinodAuthor Commented:
i think it would be helpful if you send me the link that you are talking about.
0
myvinodAuthor Commented:
hi twalgrave... the links were of not too much use, but they sure opened doors to new ideas. i have developed my solution with the help of asynchronous calling using an ActiveX Exe. I am killing the word objects using findwindow and killprocess APIs. After killing an instance i am again creating a new instance of word and continuing with the next file, but at times i get a message window saying that word has encountered an error and needs to close. It seems that the problem is never ending.

this article from microsoft states  "Why powerPoint instance remains in memory even after it is set to nothing by automation client", i think this applies to word also

http://support.microsoft.com/default.aspx?scid=kb;EN-US;249169

according to this article i cannot create module level objects(article suggest using procedure level objects). i am forced to create module level objects so that i can implement the asynchronous calling.

i have gone through your profile twalgrave and i hope you sure will have an idea or work around for me.
0
twalgraveCommented:
I don't know if you gave me the wrong article but I don't see anything in there about module level versus procedural level variables.  I think it does tell a story about PowerPoint problems, but I don't think it goes beyond PowerPoint (except using PP via VBA from another app, but the problem appears to reside within the reference count handling of PP itself.)  When the reference count reaches zero-it is supposed to remove itself from memory.  Now I ran into a problem like this with VB3 where if the external name of the DLL did not match the internal name of the DLL, then each unique finction call from within a DLL would increment the reference count of the DLL and when VB released it's hold on the DLL, it would decrement the count, but that was VB3, with the Oracle Driver.  Anyway, I don't think  that this is your problem.  I suspect what is happening in your most recent text provided is that you are killing the instance of word and it is not finishing before you try t0 start another instance of Word.  I ran a test and although I didn't get the same error as you are showing, it did produce interesting results.  Here's the test:
1) Start an instance of word manually (not through code).

2) Then minimize the instance

3) Then do Start...Run and type in winword, but do not press enter yet

4) Then press ctrl+Alt+Delete to get to task manager and manually kill the word instance you manually started.

5) As soon as you do that, quickly go to the Start...Run window where you already typed in Winword and press the OK button.

You would expect to see a kickoff of a new instance of winword, but I didn't and could repeat this several times.

With that in mind, I suspect I'm getting the error behind the scenes, but without any code in the Start...Run functionality to test for the error condiution, it simply errors out and quits te second copy of Word.

With this in mind, I would do this after killing the old instance and starting the new one:

'Kill the old instance
....

doevents
Sleep 3000
doevents
....
'Start the new instance.



0
myvinodAuthor Commented:
I have done the above said. but it isn't doing well atleast the number of times that I get the error has reduced. Also, one drawback of killing the word instance is that the document which is being opened leaves a ~<document name> file. The next time when it is opened it gives an alert(doc caused serious problem last time). I have decided to go with simple exe and discard the ActiveX exe solution.

One more specific problem that i have seen with Word XP is that word documents format 6.0/95 generates a change style info(show repairs) alert. The same documents when opened in Office 2000 opens without any alerts. Is there any specific way to get around this by setting properties in word XP.
0
twalgraveCommented:
I haven't found a way to disable that.  Let me know if you come across it though as I'm sure I will run into that some day.
0
CleanupPingCommented:
myvinod:
This old question needs to be finalized -- accept an answer, split points, or get a refund.  For information on your options, please click here-> http:/help/closing.jsp#1 
Experts: Post your closing recommendations!  Who deserves points here?
0
myvinodAuthor Commented:
Thank you twalgrave and dmang for your support.  I was finally able to solve the problem by using the ActiveX exe solution. The activex exe runs ashyncrounously and checks if the word application is not responding by throwing an event to the my VB application. I handle the conditions using some flag variables.  But in the due course of development i was encountered with many other alerts/messages thrown by the VB application, which was overcome by changing the properties while opening word.
     I would like to split the point between you two for the support.
0
twalgraveCommented:
Thank you and I'm glad to see you got it working.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.