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? 

This issue is being reported and I see that it is spreading.

I would like to know if all users who have this issue are currently using Vista with the latest patches as it does not appear with our XP installations.

hcox said:

This issue is being reported and I see that it is spreading.

I would like to know if all users who have this issue are currently using Vista with the latest patches as it does not appear with our XP installations.

hi...

i am experiencing the same prob with XP also...

 Hi,

it apparently doesn't matter to IG, but we are seeing the same problem here.
We too have a very complex application that updates datasets bound to WinGrids and other UI elements, probably on different threads.
We are very disappointed (but not surprised) that IG does not handle those situations.
And please IG support people, show me where in the Framework documentation it states that update to data bound to UI elements must be performed on the UI thread?

Forcing our application down to single threading is either impossible or beyond ridiculous...

And no, we don't have a "simple" example that causes this issue. We have been writing this app for 5 years and are not getting paid by IG to debug their framework. We pay them to deliver us a working product (and quite a bit of money I would say!).

 It probably doesn't make this issue mover forward, but I have spend days trying to nail down that issue and it has now cost us a ridiculous amount of money and still isn't fixed.

Back to the drawing board! 

eric_liprandi said:

We too have a very complex application that updates datasets bound to WinGrids and other UI elements, probably on different threads.

What exactly do you mean by "probably"? If your application is using multiple threads, you must know you are doing so.

eric_liprandi said:

show me where in the Framework documentation it states that update to data bound to UI elements must be performed on the UI thread?

Anything you do on any thread needs to be extremely careful about having effects on any other thread. If you perform an operation on a thread and call a method on another thread without marshalling, you are certain to cause all sorts of problems in your application that will be very difficult to debug. This is well documented by Microsoft. 

eric_liprandi said:

Forcing our application down to single threading is either impossible or beyond ridiculous...

No one suggested that you do so. But if you are going to use multiple threads in your application, then you need to use them properly and be aware of the potential pitfalls. If you perform an action on one thread and that action results in an unmarshalled call to antoher thread, this will cause a problem. This is not specific to Infragistics control, but applies to anything you do in Windows programming.

eric_liprandi said:

And no, we don't have a "simple" example that causes this issue. We have been writing this app for 5 years and are not getting paid by IG to debug their framework. We pay them to deliver us a working product (and quite a bit of money I would say!).

If you can't narrow down the problem so a simple example, then how can you be so sure that the issue is a bug in the Infragistics controls? If Infragistics support debugs every applicatoin by every developer who thinks that the problem might be a bug in one of our controls, we would quickly run out of time and resources to do anything else. If you beleive the problem is with one of our controls, then we are always happy to investigate the issue. But we cannot simply wave a magic wand and determine the cause of an error in a large applicatoin any more than you can. So Infragistics (quite reasonably, IMO) asks that if you are reporting a bug in the controls that you demonstrate that bug to us in some way so we can check it out, determine the cause, and get it fixed.

The fact that an issue is not easily repeatable is one the most common factors in a threading issue. Threading crashes happen seemingly at random, long after the actual method that caused the error has completed. So the fact that your issue is not easily duplciatable in a simple example is an indication that it may be caused by threading.

I asked this before and I will ask it again. What, specifically, are you looking for Infragistics to do in order to solve your issue that we are not doing? I am open to reasonable suggestions. But how exactly can we address a problem that we cannot even duplicate or even be sure that the problem is related to our controls?

 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! 

hcox said:

this issue has only become visible to all us when using IG tools, hence by association you are getting landed with these queries.

That's only because that's what you happen to be using. If you were using the inbox grid or some other third-party grid, I'm sure you would encounter the same, or similar, issues. Assuming that the issue is actually a marshalling problem.

hcox said:

it would be useful for infragistics to provide guides, faq and sample resolutions on this matter

I'm not so sure about quides and FAQs. The issue being discussed here has nothing to do with the Infragistics controls. What we are talking about here is how to properly handle multi-threading in a Windows Forms app. It's really Microsoft's place to document this kind of thing and I am sure they have plenty of documentation on it.

I suppose we could provide a sample - but a sample of what, exactly? There are an infinite variety of data sources and ways that you could be using mulitples threads. So I'm not sure how useful a sample would actually be to anyone, since it would only be a sample of one limited case.