I am a developer for a sales application for a medical product distributor.
The sales application uses WinGrid from Infragistics version v2.00.5000 and v3.
Sales reps (800+) are reporting the Red X problem.
I read all the posts on this forum related to Red X and the claims as to why it occurs.
My sales application DOES NOT DO ANY BACKGROUND THREAD UPDATING OF grids!!!
Yet the Red X problem shows up now and then and I am unable to reproduce it.
It seems intermittent and unpredictable.
The sales reps hate it because they stand to loose data when this happens.
I am taking flack for this from upper management.
IS THERE A KNOWN RESOLUTION TO THIS PROBLEM???
Is INFRAGISTICS prepared to help us resolve this problem?
Hi,
PSSDDev said:The sales application uses WinGrid from Infragistics version v2.00.5000 and v3.
I'm not sure what this means. That is not a version of NetAdvantage that I am familiar with. Our version numbers use a format like 9.1.20091.1000. So there is no V2.00.5000 of Infragistics NetAdvantage. Can you tell me exactly what version of the assemblies you are using? Do you have the latest Hot Fix?
PSSDDev said:My sales application DOES NOT DO ANY BACKGROUND THREAD UPDATING OF grids!!!
Does your application use any threading at all? It's not just the updating of the grid on another thread that can cause an issue like this. It's also very easy to inadvertently use a thread to affect something that may affect the BindingManager or the data source.
The fact that the problem is not reproducible and that it happens seemingly at random is a strong indication that there is some kind of threading issue occurring, although this is not a certainty.
PSSDDev said: IS THERE A KNOWN RESOLUTION TO THIS PROBLEM??? Is INFRAGISTICS prepared to help us resolve this problem?
The red X usually indicates that an exception occurred during the painting of the grid. This is commonly caused by threading issues, but there have been some known bugs that caused the same kind of error in the past. So my first recommendation would be to make sure you have the latest Hot Fix.
If that does not help, then we would need more information to track down the issue. When the error occurs are you able to get a call stack? Is there any more information in the error message?
Mike, thank you for your response.
Here are the references I find in my project...
Infragistics.Shared.v2Infragistics.Win.UltraWinEditors.v2Infragistics.Win.UltraWinGrid.v2Infragistics.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
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.
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.