Update a DataGridView without loosing current cell focus

Question

My program is split in two parts:

1. A client, in Windows Forms.
2. A server, made with WCF on a remote web server (IIS).

The client will be used my many different users, in same times.

I have many DataGridView in my client. Those DataGridView are bind to (different) generic list of objects provided by the web service.

I need to refresh the content of those DataGridView quite frequently. I use a timer on the client that call a refresh method.

BUT my problem is: if I use Invalidate(), just the content of current displayed row are updated; if another use remove or add a new object (row), current user won't see it. If I refresh the data with rebinding the data, the current selection is lost... Imagine the nightmare if the user was updating data... (yes I could stop the timer when the user edit a cell and restart when user has done his changes, but I hope to find a better method!).

Anybody have see problems like those? Anyone have suggestions?

thank you

Answer 1

What you are describing is a distributed system. You need to implement locks and synchronisation for this kind of software. Sure you can leave it out, but your result will be crap.

1. Datagridview should only be there for reading.
2. Editing rows should be done outside DGV. (If all objects are different, well then you are going to have fun)
3. Lock messages should be sent to the server, which keeps track of this.
4. Locked objects should be possible to read for other users. Not writing.
5. Timouts for locked objects need to exist.

Sorry to dump this on you but your problem is way bigger than you think.

Answer 2

Agree with @WozzeC's answer. Database locking is the preferred solution.

But if you can't use locking and don't mind more accesses to the database, you can simulate locking by adding a column to the table(s) you're updating, setting the column in each row to some unique session-ID or user-ID when that user attempts to update/modify that row.

This requires a database access at the point when the user selects the row for modification, but that has the added benefit of checking that the row still exists in the database (ie, it was not deleted by another user seconds before).

Of course, since this is not true database locking, you then have to worry about user sessions that terminate (ie, their PC crashes) without freeing the rows he is modifying. Added a "checkout" timestamp column to the table allows you to allow a user's lock to time out after some reasonable amount of time (eg, 20 minutes).

Again, this approach is not without its problems, but it may give you enough of what you're trying to achieve.

Addendum

If you can't add columns to the tables you're modifying, you may have to add entirely new tables that store the user pseudo-locks. Of course, this means that all apps that modify the tables must cooperate and also use the pseudo-lock table.