Thanks Mike,

We will take out the background auto-save thread and give this a try.

Upgrading to the latest which we have the license for it is probably not an option at this point.

Thanks

Even if your background thread is only reading the data, this could certainly be the cause of the problem. The BindingManager is not thread-safe, nor are any DotNet controls that I know of.

Depending on how you are reading the data, you could be causing the Position of the CurrencyManager to change. Or, you could be attempting to read a value at the same time the grid or the BindingManager is trying to update it.

So I think your idea of removing that threading code and testing it out is a good one.

Beyond that, there's not much we can do with version 2 of NetAdvantage. That version is over 6 years old and is not being updated any more.

So if removing the threading doesn't work, then next suggestion I have would be to update to the latest Version of NetAdvantage and try that.

But I suspect removing the threading code will fix it. Everything you have described here points to a threading issue.

Mike, thank you for your response.

Here are the references I find in my project...

Infragistics.Shared.v2
Infragistics.Win.UltraWinEditors.v2
Infragistics.Win.UltraWinGrid.v2
Infragistics.Win.v2

All Version 2.0.5000.41 Runtime version v1.0.3705

This must be an old version and we never upgraded. Our license is current and covers the latest though.

On my dev box I see a bunch of individual controls docs installed and then this...

UltraSuite(TM)

ActiveX(TM) Controls

Version 3.02

March, 2002

It looks like I have a mix of v2 and v3 installed of what used to be called "UltraSuite" at some point.

Threading

Actually there is a single piece of threading taking place in this application.

Ironically it was done as a safeguard against the Red X problem so that sales reps do not loose data when Rex X shows up.

There is a thread that kicks in every 5 seconds.

It traverses the object collections bound to the grid and serializes them to an XML file on disk.

This goes one way only and never gets back to the grid.

On startup the application checks if there is an xml file written,

if so it deserialises it into object collections and binds it to the grids.

The objects saved via this thread represent the current order the rep was/is working on.

There is a possibility that this may be a problem as you suggest. For starters it runs too often (5s).

We are prepared to take this thing off and deploy to the field and see how it affects things if you think it may be an issue.

At this point we are wiling to try anything.

I sent you info on the exact version of the grids we are using in the hope that you might find that there is a know fix on record.

I have also asked our help desk to retrieve the exact stack trace that is written to the event log when Red X happens.

Hopefully we may get to the bottom of this.

Do you think it might give me more clues as to the source of the problem if I derive a class from the grid,

override OnPaint, do my own error handling (e.g. write details to event log) and then call the base class OnPaint()?

 Like I said, I am willing to give anything a shot, the only downside is deployment to 800+ laptops takes time.

I have spent a whole day with a laptop by my side in the lab and tried to force this problem to happen to no avail.

Some reps never experience it yet some see it almost daily.

There is no particular pattern as to what they do that causes this.

Our support manager has traced 33 reps who have reported this problem, out of ~800.

33/800 is not bad and the maximum frequency of occurance is 3 reports of Red X at most.

The trouble is those 33 keep barking about this. I understand where they are coming from.

I will provide you with more information that may help you help us.

Thanks