Word error: The message filter indicated that the application is b

[Rob Stewart]

Is anyone able to shed some light on what causes the "The message filter indicated that the application is busy" message to be displayed in Word (2003)?

We have c# managed code attached to a Word doc that does some processing on Document_Open(). It has been working fine on development machines, however system test machines are showing the message.

Initially, in development, we had to spawn off the Document_Open() processing in its own thread to get around this error, and it did the job. Given it's now appearing on other machines, it would appear to be a timing issue of some sort.

I've searched on the error, and it seems it could be caused by one of many things. Just wondering if anyone can offer some suggestions to get around it?

Cheers,
Rob

 

[Peter Huang]

Hi Rob,

Firstly you may try to take a look at the two links below.
BUG: Automation Error 8001010A when Automating Word 2000 (246018)
http://support.microsoft.com/default.aspx?scid=KB;EN-US;246018

INFO: Corrupt Normal.dot Causes Errors When Automating Word (247028)
http://support.microsoft.com/default.aspx?scid=KB;EN-US;247028

You may have a try and let me know if the problem persists.
If yes, what is the version on your develop machine, is the develop machine
and the problem machine are of the same office version 2003 ? Because the
office com object is back-compatible, so if we wants to make the
application works on office 2000 and office 2003(just an assumption here),
we need to build the application with office 2000.

Hope this helps.


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Rob Stewart]

G'day Peter,

Thanks for your repsonse - I had seen those 2 articles. The computers do not have Norton AntiVirus installed, and the Normal.dot is valid.

The test machines are Office 2003, same as development.

We seem to have worked around the problem by introducing a delay (Thread.Sleep). When the document opens, we have a "Startup Wizard" form that displays. This is c# managed code. When the form closes, some inserting of XML tags/text etc occurs in the document, based on the user's selections on the form. This is where we were seeing the Messasge Filter message.

As the form closes, we are kicking off a thread to do the XML inserting etc mentioned above. This is where we've introduced the Thread.Sleep - at the top of this thread. We slowly increased the delay until we stopped getting the Message Filter message.

So, for now we seem to be OK. However, rather than fudging a fix with a sleep, I'd prefer to find out if there's a way we should be structuring our code to avoid this problem. Or is this just something we have to live with attaching managed code to a Word doc?

Thanks again for your help,
Rob

 

[Peter Huang]

Hi Rob,

From my understanding, you have a winform application, after it is running,
you will automation the Excel and then popup another winform(modal or
modeless?), then the user will input some onto the popup winform and then
click OK.
Now you will spawn another thread to apply the change to the Excel, and now
you will get the error message?
If I have any misunderstanding, please feel free to let me know.

Also can you provide a simple reproduce sample and mail to me by removing
the "online" from my email address so that we can do further
troubleshooting.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter Huang]

Hi Rob,

Here is another article for you about Threading support in Office.
From the article we know that background threads cannot call into the
Office object model.

Threading Support in Office
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_wrcore/h
tml/wrconthreadingsupportinoffice.asp

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Rob Stewart]

Hi Peter,

We have a winform app in the form of code attached to a Word document via VSTO (the document ALSO has a Smart Document DLL attached to it).

Early in development (8 months ago), we had the VSTO code displaying a form on document open. On closing the form, it was to perform some actions on the Word document (insert text etc). However when the form closed and attempted to insert the text, we got the "Message Filter..." message. It turns out that when the form closed, the document state was not quite ready due to the Smart Document component still initialising (setting up the Task Pane etc.).

So...we introducted a thread with a small delay that inserted the text upon closing the form. That has been working fine in development, however we are now seeing the "Message Filter..." message again in system testing, presumably due to different speed PCs etc.

If we increase the delay enough (15 seconds), we get around the problem...but this delay is unacceptable.

Unfortunately no, I can't really send you an example as I'd have to scale it down so much it would no longer accurately represent what we're doing - the Word document is being launched from a Sharepoint portal (via a javascript that launches Word), and there is a lot of SQL server database access upon document load. So it's not really feasible to send you an example.

I think we're going to have to redesign some of our code, after reading the document you referenced int eh other post (Threading support in Office) - that was quite helpful, thanks.

This is all probably a result of us having both VSTO, VBA *AND* smart doc code attached to the one Word document. We'll just have to play around with different approaches, I think.

Thanks again for your time Peter. If you come up with any ideas, I'll be listening!

Regards,
Rob

 

[Peter Huang]

Hi Rob,

I think the best choice is to re-design the code to ensure that the Smart
Document Dll have done the job before the windows forms is going to close.

Or you may try to use global variant to synchronize the operations between
the Smart Document DLL and the Office CodeBehind dll.
e.g. Here I assume the smart document dll will run first.
In the Smart Document dll, you can create a named mutex, and then do the
smart document job, afterwards we will release the mutex.
In the windows form's closing events handle method, you may try to judge if
the mutex has been released by using the mutex.waitone method.
Please try to use the public virtual bool WaitOne(TimeSpan, bool) version
and use a very tiny TimeOut value, so that the UI will not be blocked
because of the thread block. The return value will tell us if the mutex has
been released, i.e. if it has been signaled.

Also you may decide what to do in the winform closing event, when the Smart
Document dll is busy(i.e. the mutex is not released).
e.g. We can do nothing and tell the end user,the Word application is busy.
Or wait in a while loop so that the thread will not be blocked.
while(!var_mutex.WaitOne(new TimeSpan(0, 0, 0), false))
{
Application.DoEvents();//Running the message loop.
}


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Rob Stewart]

Hi Peter,

I thought we were onto a winner with your mutex suggestion, but I'm having trouble implementing it.

The problem is that Word seems to wait until both Document_Open() in the codebehind AND the smart doc DLL constructor have completed before it attempts to draw the Document Actions task pane. It is not actually the smart doc DLL that draws the task pane, therefore I am unable to have a mutex released once the pane is rendered (as it's done by the Word application and I cannot hook into that).

So I'm back at square one - attempting to reorganise code, as we have to have this form appear at startup, and we also need the smart document component.

I'll investigate attaching the smart doc component (i.e expansion pack) to the document programmatically - any idea if this is possible? That way I can allow the codebehind to have it's form on Document_Open(), and then attach the expansion pack once the form has closed.

Rob

 

[Rob Stewart]

FYI it turns out my suggestion in the previous post of adding the smart document expansion pack programmatically will not solve the problem...as the document is being opened from Sharepoint, if there is no Document Actions task pane present, the Shared Workspace task pane shows instead. Which leaves me back with the original problem!

Rob

 

[Peter Huang]

Hi Rob,

Do you mean the problem occurred when the task panel is visible?
If so, you may try to close the task panel by calling the code similar with
below.

CommandBars("Task Pane").Visible = False

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Rob Stewart]

Hi Peter,

I've thought of that, but it doesn't help as by that point the document has already opened, and the task bar has been displayed - i.e. the error has already occurred. I need to prevent the task pane from being loaded AT ALL. I don't think this is possible.

Rob

 

[Peter Huang]

Hi Rob,

I am sorry if I have any misunderstanding.
Do you mean the error will only occur when you close the modeless form or
it will occur when open the document?

Also have you tried catch the exception which will cause the error message
dialog to occur in a try...catch block to see if this will help?
Or you may try to call the code which will cause the error message dialog
to occur in a BeginInvoke delegate method to see if this will resolve the
problem.

e.g.
System.Windows.Forms.Form fm = new Form();
protected void ThisDocument_Open()
{
fm.Show();
fm.Click+=new EventHandler(fm_Click);
}
public void InvokedMethod()
{
MessageBox.Show("Invoked");
}
private void fm_Click(object sender, EventArgs e)
{
fm.BeginInvoke(new MethodInvoker(InvokedMethod));
}

HOW TO: Populate Datagrid on Background Thread with Data Binding by Using
Visual C# (318607)
http://support.microsoft.com/default.aspx?scid=KB;EN-US;318607

Control.BeginInvoke Method
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfSystemWindowsFormsControlClassBeginInvokeTopic.asp

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Rob Stewart]

Hi Peter,

The modal (NOT modeless) form is displayed during DocumentOpen(). Once the form closes, some processing on the document is done (still in DocumentOpen() ). It is this processing (inserting some text) that is causing the error, as Word is attempting to render the Task Pane at the same time - the same time as we're trying to insert text.

As a desperate measure to get us by in system testing, I have removed the form from DocumentOpen() and put in a button on a menu bar. The user needs to click the form once it's open.

I will look into the suggestions you have made in your post and let you know how I go.

Thanks for all your help mate.

Regards,
Rob

 

[Peter Huang]

Hi Rob,

For Model dialog, we need to do something more to call the begininvoke.
fm.ShowDialog();
IntPtr b =fm.Handle; //The line is necessary, because after the
ShowDialog, if we close the dialog, the hwnd of the fm has been disposed,
we need to initialize it again.
fm.BeginInvoke(new MethodInvoker(InvokedMethod));

I look forward to your test result.


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.