Apologies if this answer exists elsewhere, my search didn't return anything.
Here's my situation. I have a form containing some buttons and a WinGrid. On button press by the user, server side updates are performed using data from the grid. The update communication is performed in a background thread so that the user can access other parts of the application. The downside is this leaves the wingrid enabled where the user could make changes while the update is in progress.
The simplest option is to set the .Enabled property on the wingrid during processing, and re-enable after it's complete. However, project management has deemed the graying out of the grid "ugly" (even though it's been stressed to them that this is consistent windows behavior) and not an acceptable answer.
I've attempted to go through all the appearance objects in the grid and set their disabled colors to the same value as the non-disabled colors (ie .ForeColorDisabled = ForeColor) at design time, in the hopes that when setting .Enabled = false, I'd get the behavior I'm looking for without any visual change. However this doesn't appear to be doing anything, I'm still seeing the grayed-out component.
My questions are:
1) Is the above approach feasible and maybe I'm just missing something?
2) Is there perhaps another way to get the behavior I'm looking for? (I should note that what I'm looking for is not solved by just setting the grid to ReadOnly, I still need to mimic a truely disabled component (ie clicking column header doesn't resort).
Thanks!
Hi,
Updating, modifying, or even accessing the grid's DataSource on a background thread is an extremely dangerous thing to do and I strongly advise against it.
You are correct that if the user tries to edit the grid, it would certainly cause a problem. But you are assuming that this is the only interaction between the grid and the data source.
The data source is most likely sending notification to the grid every time something changes. This is likely to cause an exception - and an exception that will be extrememly difficult to track down.
Further, the grid might try to access the data source at any time. For example, if the mouse moves over a cell or the grid is invalidated in some other way. Once again, this could cause your application to become corrupted and cause an exception.
If you are going to modify the data on a different thread, then the only truly safe way to do it would be to unbind the grid first.
Here's another discussion of threading which goes into some more detail:
Work with a dataset bound to a grid on a separate thread - Infragistics Community
I have to agree with Mike. I didn't think about multi-thread access. TRUST ME. I found this out the hard way. I had an application where I was spinning of another thread against a datasource and my users began to experience what appeared to be random program lockups. We wasted a lot of time trying to figure out what was going on. But I did this going in with my eyes wide open because I already knew that datasets were not thread safe. I thought I could get away with it.The moment I stopped spinning off that other thread the lockups stopped.
In the current version of my program I still use a seperate thread to talk to the server, but I don't touch my datasource until I'm back in the main thread.