Multithreading vsto 2003

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Sarge - 20 Apr 2006 06:25 GMT

Hi all,

I am writing a VSTO 2003 solution using Excel as the front end (please
don't ask me why)

It is a real time application that needs to repeatedly update data in
worksheets and charts. Sometimes in response to user events at other times
when the clock changes.

I seem to get COMExceptions repeatedly when performing all sorts of
things

Setting application.ScreenUpdating property
Calling range.CopyFromRecordset

System.Runtime.InteropServices.COMException (0x800AC472)

I understand that these errors get produced when Excel is not prepared
to accept any external commands.
Some potential reasons for this is the user is editing a cell/formula or
has a dialog open, is computing stuff... I guess the list goes on.

I am not aware of any way to determine if excel is in a receptive state
from within C#.

Also does any one have any suggested methods for queuing up events while
I wait for Excel to come available?

Cheers

Mark

Reply to this Message

Alvin Bruney - 21 Apr 2006 13:39 GMT

are you using control.invoke? you can't just call excel functions on child
threads right?

Signature

________________________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Professional VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

> Hi all,
>
[quoted text clipped - 27 lines]
>
> Mark

Reply to this Message

Sarge - 23 Apr 2006 21:31 GMT

Hi Alvin,

yes am using the control.Invoke to shift(marshal, is that the correct term?)
the call onto the UI thread.

I am using a named UI thread and checking the name of the CurrentThread to
determine if the Invoke is required. The control.InvokeRequired doesn't seem
to be detecting the fact that the calling thread is not the UI thread. This
seems to work fine.
public static string uiThreadName = "UI Thread";

public static bool IsRunningOnUIThread

{ get{return uiThreadName == Thread.CurrentThread.Name;}

}

Also I use a static reference to a form that was created on the UI thread to
do the Invoke on as there doesn't seem to anything on the OfficeCodeBehind
window to do the Invoking which seems quite involved from my inspection of
the Invoke method via .Net Reflector

private void MyAppError(string message, Exception ex)

{

if (IsRunningOnUIThread)

DisplayException(message, ex);

else

Invoke(new MyApplication.ErrorHandler(MyAppError), new
object[]{message, ex});

}

private static MessageWindow messageWindow = new MessageWindow();

public static object Invoke(Delegate method, object[] args)

{ return messageWindow.Invoke(method, args);

}

Cheers

Mark

> are you using control.invoke? you can't just call excel functions on child
> threads right?
[quoted text clipped - 30 lines]
>>
>> Mark

Reply to this Message

Alvin Bruney - 25 Apr 2006 16:35 GMT

Couple of issues here in this approach. The test, though strange, will only
work if the GUI thread is the initializer. If there is even the slightest
chance of this not happening, the call will fail with COM exceptions for
cross thread access. I don't actually understand your reason for not wanting
to use IsInvokeRequired.

Signature

> Hi Alvin,
>
[quoted text clipped - 79 lines]
>>>
>>> Mark

Reply to this Message

Sarge - 25 Apr 2006 23:06 GMT

I see your point.

I did originally try using the Control.InvokeRequired but it didn't seem to
work at the time. I have changed it to use the control.InvokeRequired on the
messageWindow which now works and detects the non UI thread correctly.
Thanks.

I still can't detect when Excel can not be modified.

From what I have been reading some of my issues could be related to the fact
that my threads are managed by the ThreadPool which supports the MTA type
apartments and excel is STA. Any thoughts on this or know of any
recommendations for threading in excel and VSTO.

Cheers

> Couple of issues here in this approach. The test, though strange, will
> only work if the GUI thread is the initializer. If there is even the
[quoted text clipped - 86 lines]
>>>>
>>>> Mark

Reply to this Message

Alvin Bruney - 26 Apr 2006 00:35 GMT

I don't understand the other part of your problem. What happens when you try
to update a worksheet? Unless the worksheet is protected, you should have
unrestricted access to the cells and ranges on the spreadsheet surface. Are
you getting exceptions?

Signature

>I see your point.
>
[quoted text clipped - 102 lines]
>>>>>
>>>>> Mark

Reply to this Message

Sarge - 26 Apr 2006 06:08 GMT

Yes, sorry if that wasn't clear.

The exceptions come typically in 2 flavours.

One occurs if a cell or some other blocking operation is being edited. In
the case below I am updating some style information while a cell is being
edited. In this case I would expect to be able to determine it is in modal
state so I can take some other action.

System.Runtime.InteropServices.COMException (0x800A03EC): Exception from
HRESULT: 0x800A03EC.
at System.RuntimeType.ForwardCallToInvokeMember(String memberName,
BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData&
msgData)
at Microsoft.Office.Interop.Excel.Range.set_Style(Object )

The other occurs it seems at times when the application is viewing the chart
and the underlying Worksheet is having data copied into it via a old ADO
RecordSet. This technique is the fastest waay to copy a significant amount
of data from c# into the excel workbook. I have checked all input variables,
the null object reference seems to be created inside the interop code. The
code does not fail all that often, only it seems when excel is busy doing
something.

System.NullReferenceException: Object reference not set to an instance of an
object.
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr,
Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture,
String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr,
Binder binder, Object target, Object[] args, ParameterModifier[] modifiers,
CultureInfo culture, String[] namedParameters)
at System.RuntimeType.ForwardCallToInvokeMember(String memberName,
BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData&
msgData)
at Microsoft.Office.Interop.Excel.Range.CopyFromRecordset(Object Data,
Object MaxRows, Object MaxColumns)

Any suggestionson how to debug any of this?

Cheers and big ups in advance

>I don't understand the other part of your problem. What happens when you
>try to update a worksheet? Unless the worksheet is protected, you should
[quoted text clipped - 107 lines]
>>>>>>
>>>>>> Mark

Reply to this Message

Alvin Bruney - 26 Apr 2006 14:33 GMT

Excel is not built to support multiple concurrent users. As such, there is
no graceful means to handle concurrency except from exception triggers. I
suggest you wrap calls that you think will fail due to concurrency in an
exception block and have your code wait a while, using
System.Threading.Thread.Sleep(100) for instance, before trying again.

Signature

> Yes, sorry if that wasn't clear.
>
[quoted text clipped - 149 lines]
>>>>>>>
>>>>>>> Mark

Reply to this Message

Multithreading vsto 2003

Free Magazines