Hi, did you have a link to the other thread? 

If not, no worries, I think I can probably figure out marshaling it.

Thanks.

Hello,

I apologize I did not include the link. Here it is: http://es.infragistics.com/community/forums/p/15832/57635.aspx#57635

Thanks. I just read this. It's similar (and we've had similar MT issues we've had to be careful with other IG controls) but... there's one key difference with what I'm doing in my test. I'm creating the workbook in a worker thread completely before binding. Once the workbook is finished building, it fires a message back to the UI to create a form and bind the workbook and the worker thread goes away. This binding/form creation step is marshaled.

So, are the workbook/worksheet/cell/etc classes not thread safe?

Thanks

One other thought that occurred to me. Even if you are properly marshaling the workbook to the UI thread, there's another reason why it might have a problem. If the background thread is still going and performs any operations on the same workbook, it would be operating on another thread and that might cause the same kind of issue. 

Thank you for letting my know your progress on this issue, and please let me know if you reproduce the issue.

Please let me know if I can be of any further assistance.

Totally agreed - it smells of MT/UI issues. This was my first thought as I've had similar issues with ultragrid and databinding where errors pop out of nowhere when I mistakenly access the underlying data from another thread.

Unfortunately, now I'm not able to reproduce it (ARGH!) So, I'll have to wait until I see it again to chase it down. I triple-checked I'm marshalling the workbook to the UI - definitely being marshaled. I confirmed by asserting no invoke required in the UI creation. At the point of UI creation and the point of exception the worker thread was definitely no longer running.

Thanks Mike! I'll repost as soon as I can reproduce.

Hi, 

The term thread-safe doesn't really apply here. Thread-safe means that a control is safe to use in a multithreaded environment, but not that the control itself supports cross-thread interaction. In this case, you are asking if the workbook workbook/worksheet/cell/etc are mulit-threaded. They are not. In fact, no Winforms controls are, nor is the DotNet framework as far as Windows Forms goes. 

The exception you are getting here is, in my opinion, definitely a threading issue. It has all the hallmarks of such an issue. The exception occurs on a paint and the exception indicates that something in the code has exceeding the bounds of an array or collection. From long experience, this is exactly the kind of exception you get from a threading issue. When I read your original post, I said "threading issue" to myself even before I read the rest of your post where you mention that you are creating the workbook on another thread. 

If, as you say, the workbook is properly marshalled to the UI thread, then there shouldn't be a problem. But I find that very hard to imagine, since this is so clearly and obviously a threading problem. If that is the case, and the workbook is properly marshalled, then you should be able to reproduce the exception when creating the workbook on the UI thread. Is that the case?