[HELP]Ultragrid ERROR "datatable internal index is corrupted: 13"

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.