Hi All,
Although I'd ideally like a response from someone from the Infragistics support team, I thought I'd post this question here in case it may be helpful to others (or if anyone else has any information on this)...
I am currently using an UltraGrid bound to a DataTable with a CalcManager that are all constructed and used on a seperate thread. The CalcManager is Manual and deffered calculations are disabled.
Whenever a change is made to a seperate UltraGrid (formulas added, removed edited) I intend to replicate this in a seperate DataTable by simply applying the formulas to this UltraGrid on a seperate thread and performing a ReCalc on it's CalcManager.
This has been working fine, except we are occasionally experiencing a cross-threading issue. It has been difficult to determing the cause (especially as the exception thrown does not name the control or object that was cross-threaded). After clearing up the code a bit and ensuring all GUI controls are accessed on the thread that they were created on, we are still seeing this issue.
My question is: if a CalcManager is Manual, deffered calculations are disabled and it is created, assigned and modified on the thread that the UltraGrid it is assigned to was created on, can I be certain that if I call myCalcManager.ReCalc(-1) it will: (a) Hang until all cells in the grid are up-to-date, and (b) the CalcManager is thread-safe here and is not delegating tasks on other threads behind the scenes?
I would like to rule this out of the possible issues, so any clarification would be greatly appreciated!
Cheers,
Richard
P.S. I know this isn't really the place for it as it's more of a general Windows issue, but does anyone know why the Control/object's name that is being cross-threaded would not appear in the exception? Is it simply the control does not have a name?
Richard said:(a) Hang until all cells in the grid are up-to-date
This should be the case. If it's not, I'd consider it a bug.
I assume that when you go through the process of updating the formulas on the second thread from the UI Thread that you are properly marshaling, of course. If you are calling into the second thread while the calculations are in progress and not marshaling, it could certainly cause a problem.
Richard said:the CalcManager is thread-safe here and is not delegating tasks on other threads behind the scenes
I would not say that the CalcManager is "thread-safe", as that term has a different meaning than I think you are using here. The CalcManager is not creating any threads of it's own, though. It's asynchronous behavior is handled using a timer, not a thread. And in Synchronous or Manual mode, even the timer is not used.
Richard said:P.S. I know this isn't really the place for it as it's more of a general Windows issue, but does anyone know why the Control/object's name that is being cross-threaded would not appear in the exception? Is it simply the control does not have a name?
Threading issues are notorious difficult to track down because the error almost always occurs at some later point long after the damage has been done rather than when the problem actually occurs.
Thanks for the swift reply Mike.
Mike Saltzman"] (a) Hang until all cells in the grid are up-to-date This should be the case. If it's not, I'd consider it a bug. [/quote] Thanks. We looked into this further and it was hanging the correctly, the issue was instead that I wasn't accepting the changes in the DataTable before taking a copy. Mike Saltzman"]I assume that when you go through the process of updating the formulas on the second thread from the UI Thread that you are properly marshaling, of course. Yes, as the UltraGrid is never shown, there is an issue with using the InvokeRequired (as the handle is never created properly or something) and so instead, I have a constantly running thread and manage fields using locks to communicate changes to the grid. i.e. The only time the grid, CalcManager or DataTable is accessed or modified is in this single method that runs on it's own delegate. Mike Saltzman"]I would not say that the CalcManager is "thread-safe", as that term has a different meaning than I think you are using here. The CalcManager is not creating any threads of it's own, though. It's asynchronous behavior is handled using a timer, not a thread. And in Synchronous or Manual mode, even the timer is not used. Yes, I think I have used the term in a bit of a silly way here. But thanks, that what I wanted to know. Mike Saltzman"] Threading issues are notorious difficult to track down because the error almost always occurs at some later point long after the damage has been done rather than when the problem actually occurs. I'm going to try to show the Grid in it's own form with it's own pump and see if the issue is resolved. I've been unable to reproduce this outside of the debugger but do not want to presume it's an issue that purely resides in debug... Thanks for all the information! I can at least be confident the CalcManager is running as I intended it. Cheers, Richard
(a) Hang until all cells in the grid are up-to-date
[/quote]
Thanks. We looked into this further and it was hanging the correctly, the issue was instead that I wasn't accepting the changes in the DataTable before taking a copy.
Mike Saltzman"]I assume that when you go through the process of updating the formulas on the second thread from the UI Thread that you are properly marshaling, of course.
Yes, as the UltraGrid is never shown, there is an issue with using the InvokeRequired (as the handle is never created properly or something) and so instead, I have a constantly running thread and manage fields using locks to communicate changes to the grid. i.e. The only time the grid, CalcManager or DataTable is accessed or modified is in this single method that runs on it's own delegate.
Mike Saltzman"]I would not say that the CalcManager is "thread-safe", as that term has a different meaning than I think you are using here. The CalcManager is not creating any threads of it's own, though. It's asynchronous behavior is handled using a timer, not a thread. And in Synchronous or Manual mode, even the timer is not used.
Yes, I think I have used the term in a bit of a silly way here. But thanks, that what I wanted to know.
Mike Saltzman"] Threading issues are notorious difficult to track down because the error almost always occurs at some later point long after the damage has been done rather than when the problem actually occurs.
I'm going to try to show the Grid in it's own form with it's own pump and see if the issue is resolved. I've been unable to reproduce this outside of the debugger but do not want to presume it's an issue that purely resides in debug...
Thanks for all the information! I can at least be confident the CalcManager is running as I intended it.