finally i can debugger to debug the error is from this line of code

  If frmMDI.UltraTabbedMdiManager1.TabGroups.Count > 0 Then
                For i As Integer = 0 To frmMDI.UltraTabbedMdiManager1.TabGroups(0).Tabs.Count - 1
                    If frmMDI.UltraTabbedMdiManager1.TabGroups(0).Tabs(i).Form.GetType.Equals(frmLifter.GetType) Then
                        If frmMDI.UltraTabbedMdiManager1.TabGroups(0).Tabs(i).Form.Text = LifterId Then
                            Dim F As frmLifter = CType(frmMDI.UltraTabbedMdiManager1.TabGroups(0).Tabs(i).Form, frmLifter)

                            If Not F.grdAlarm.DataSource Is Nothing Then

                                Dim DTAlarm As DataTable = CType(F.grdAlarm.DataSource, DataTable)

                                DTAlarm.Rows.Add(New Object() {CDate(DT), StatusId, StatusMsg, BackColor.ToArgb})

                                F.grdAlarm.DataSource = DTAlarm
                                'If DTAlarm.Rows.Count <> 0 Then
                                F.grdAlarm.ActiveRow = F.grdAlarm.Rows(F.grdAlarm.Rows.Count - 1)

                                F.lblAlarm.Text = StatusMsg
                                F.lblAlarm.BackColor = BackColor
                                F.LatestStatusIsBlinking = IsBlinking
                                F.LatestStatusColor = BackColor
                                F.LatestStatusDT = DT
                                frmMDI.tsslStatus.Text = DT & " " & LifterId & ":" & StatusMsg
                                'End If
                            End If

                        End If

                    End If
                Next
            End If

when it come to that line

Dim DTAlarm As DataTable = CType(F.grdAlarm.DataSource, DataTable)

it show me: Datatable internal index is corrupted: 13 

what is the problem? 

If you can duplicate this error in a small sample project then I would recommend submitting the issue to Infragistics Developer Support.

Otherwise, I'm not sure how much help I can offer you here if your DataTable is somehow getting corrupted. If you can debug to that line of code, does that mean you can get a call stack that shows where the exception is occurring? It might help if you post that info here.  

I had a similar problem using DoWork to fill the datasets.  Usually there would be no error, but the datasets were only partially filled.  When there was an error, it was often too vague to be of any use.  Finally I got the "System.InvalidOperationException: DataTable internal index is corrupted: '13'." error, which pointed to filling the datasets in a separate thread.  I was able to get it to work by adding "System.Threading.Thread.Sleep(200);" before the fills.  To be extra safe, I removed the separate thread call entirely, and put the fills back into form_Load, without the experimental delay.

BTW Mike, you do amazing work.  To think of what I could do if I had your patience!

 I want to thank IG for all of their support to me -- I rarely don't have a question answered or at least am pointed to in the right direction.  You guys do a great job and have no obligation to teach intermediate developers how to do mulit-threading, correctly.  

 Keep on keepin' guys.

eric_liprandi said:

But, if you want an example of professionalism, simply search for this error on the DevExpress forums/KB. Nowhere will you find posts that insinuate that a customer is stupid. Not from other contributors and let alone by one of their employees.

I'm sorry you feel that way, but I see nothing in any of my posts or anyone else's here that insinuates anything of the sort. I have done nothing in this thread (or any thread on these forums for that matter) but try to offer suggestions to help people try to resolve the problems and errors they may be getting.

If, by attempting to offer advice based on my experience, I implied that perhaps there are some developers out there who may not know everything about everything and you feel that this is insulting, then I guess I am guilty of that. But I worked in Developer Support here at Infragistics for many years and I can say with certainty that there are plenty of developers do not know everything. Many of them make mistakes. Many of them make programming errors. And some of those errors have to do with the improper use of threading. This does not insinuate stupidity on anyone's part. If everyone knew everything, we wouldn't need these forums or developer support at all.

I have not suggested anywhere here that I am absolutely certain that the error being reported here is a threading issue. All I have said is that it seems a likely cause of the problem given my experience with the controls. It's also possible that some of the issues reported here are caused by threading and some are not. Without more information, there's not much else I can do but guess. 

eric_liprandi said:

And I re-iterate that customers have no obligation to provide IG with any code sample or anything like that when they have a problem. Just imagine if we asked our customers (who are not programmers) to investigate their issues and only send us a bug request when they know where and why it fails? Would be nice, wouldn't it?

I have asked this twice already and I will ask it again. What is it, exactly, that you suggest Infragistics do that we are not doing?

All we have to go on in these posts is a call stack and that's not enough to diagnose what caused the issue. 

If a customer reports a bug in your software, isn't the first step in fixing it reproducing the issue? How do you fix an issue you cannot duplicate? If you can't reproduce the error, how would you even know if you fixed it?

If a customer tells you that your software is crashing, your first response isn't, "Oh, okay, I will wave a magic wand and fix it." Your first response it probably, "Okay, where is it crashing?" or "What area were you in when it crashed?" or "What were you doing when it crashed?" or "Can you tell me how you made it crash?"

It's perfectly reasonable for Infragistics to ask for information to help us diagnose the problem. The easiest way to do that is with a sample. If that's not possible, then we need instructions how to reproduce the issue. If that's not possible, then we need as much information as we can possibly get. So far, the only thing I see in this thread is a call stack, which is not nearly enough.  

I also do not accept your analogy. Supporting end-user software and supporting components and controls used by developers is a completely different animal. I know because I have done both. If you provide software to a customer, your software presumably has a very limited number of things a user can do with it. You limit your users to the UI you want them to have. With a component being used by a developer, there are an infinite variety of ways developers can use the controls. Your users don't have the option of creating a new thread and then trying to access your application from it.

 Ouch!

This is my second interaction with IG support. Dare I say my last? I have used DevExpress for a year an a half prior to this gig and only had excellent interactions with their support. And their controls are far superior in my opinion when it comes to API and documentation. I never really looked at performance, so I won't speak to that.

Just to clarify, yes, we actually do know what we are doing and as expected, we ensure that all data changes happen on the UI thread. Guess what? the corrupted index issue still appears, so it's not a threading issue. What got rid of the issue has absolutely nothing to do with threading or anything like that. And since we still have no clue why those were appearing, we are not even sure it is actually fixed.

But, if you want an example of professionalism, simply search for this error on the DevExpress forums/KB. Nowhere will you find posts that insinuate that a customer is stupid. Not from other contributors and let alone by one of their employees.

And I re-iterate that customers have no obligation to provide IG with any code sample or anything like that when they have a problem. Just imagine if we asked our customers (who are not programmers) to investigate their issues and only send us a bug request when they know where and why it fails? Would be nice, wouldn't it?

Lastly, how do I unsubscribe from future posts on this issue? IG forums are obviously a waste of time and I do not really get any value in receiving those messages.

Eric.

PS: found it... no need to contact me for unsubscribing!