DevForce Classic: Current cell in grid... stale data

Print Page | Close Window

Current cell in grid... stale data

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=125
Printed Date: 26-Oct-2025 at 9:50pm

Topic: Current cell in grid... stale data

Posted By: MichaelNiemann
Subject: Current cell in grid... stale data
Date Posted: 12-Jul-2007 at 8:41am

Hello, I'm a DevForce newbie... so be gentle.

I was working through the tutuorial (I appreciate the compile errors intended to keep me focused on the code details <g>)...

If I change a cell in a grid, and then DiscardChanges... the changed value remains displayed in the cell, until you change focus to another cell in that grid. Is this the intended behavior of DevForce, or am I expecting way too much at this level of the tutorial?

BTW, if you try to SaveChanges after the DiscardChanges... then the value in the grid _is_ updated to the current value (after the "No data to save" message, and without touching the grid). Of course, this is probably because the aborted Save continues to refresh the entire UI.

Anyway, just a newbie post from someone looking at the FrameWork.

Regards, Mike

Replies:

Posted By: MichaelNiemann
Date Posted: 13-Jul-2007 at 9:32am

Me again.

When I mentioned that "the grid is updated to the current value" in the BTW comment, I probably should have said "the grid is updated to the original value".

And now along the same lines only worse... I was executing the "Security_Role-Based Authorization" example, and the problem there is even worse. I logged on as "nancyd", and after changing the "order date" for one of the orders (and tabbing to the next cell), I "Discard all changes".

However, the data is permanently saved rather than discarded!

Posted By: IdeaBlade
Date Posted: 13-Jul-2007 at 2:41pm

Michael,

Yes. The fact that the change doesn't show up immediately is a known behavior of binding. Fortunately, there is a way to fix this behavior. Please read and study the advanced tutorial on "Refreshing Dependent Parents".

I couldn't reproduce your save problem. When I clicked on "Save All Changes". I got the message, "There are no changes to save".

If you want to get my completed solution, send me an email at mailto:davidk@ideablade.com - davidk@ideablade.com

Posted By: MichaelNiemann
Date Posted: 16-Jul-2007 at 6:38am

DavidK,

You must leave the cell (tab out) before saving to see the problem.

It is another manifestation of the "display doesn't show up immediately". I will check out "Refreshing Dependent Parents".

Thank you.

Posted By: MichaelNiemann
Date Posted: 16-Jul-2007 at 11:48am

DavidK,

OK, so the problem is not the framework, but a repaint bug in DataGridView. that is good. BTW, I fixed the problem with:

    private void RejectAllChanges() {
      if (mPersMgr.HasChanges()) {
        mPersMgr.RejectChanges();
        mMainTabControl.Refresh(); //added to fix DataGridView repaint bug
        MessageBox.Show("All pending changes undone.");
      } else {
        MessageBox.Show("No changes to undo.");
      }
    }

However, one answer leads to more questions...
As the "TechTip_Refreshing Dependent Parents.doc" points out, figuring out which nested component to signal from which event can be difficult (which is why I went for the "repaint everything in the container" approach).

But wouldn't a well engineered "workaround" for the DGV bug be along the lines... for the BO that I just RejectedChanges on, repaint all DGV's that are bound to the my properties (persistent and non-persistent)??

I would hope the "subscribers / bound controls" of the UI can be determined by the BO's.

Mike

Posted By: GregD
Date Posted: 24-Jul-2007 at 3:27pm

As the "TechTip_Refreshing Dependent Parents.doc" points out, figuring out which nested component to signal from which event can be difficult (which is why I went for the "repaint everything in the container" approach).

But wouldn't a well engineered "workaround" for the DGV bug be along the lines... for the BO that I just RejectedChanges on, repaint all DGV's that are bound to the my properties (persistent and non-persistent)??
<<

Probably much more often than not, you'll be rejecting changes not on a single BO, but a whole slew of them, often including different types (Employees, Order, OrderDetails, etc.)

I would hope the "subscribers / bound controls" of the UI can be determined by the BO's.

With DevForce databinding, all the bindings to a type (e.g., Employee) are collected in the Descriptors (BindingDescriptors) collection of a BindingManager. So you could tell from that which UI controls are bound to the Employee you just undid (if that's all you undid).

I suppose you could write a method that iterates through all of the BindingManagers in a particular context (e.g., on a particular form), finds out what type they manage bindings for and what control or controls they manage bindings to, and then call Refresh() on the latter, but before I attempted to automate all of it I'd be sure just to step back and think about it. I'm a strong believer in keeping things as simple as possible. That means making sure your problem merits a solution of the complexity you're undertaking.

Posted By: MichaelNiemann
Date Posted: 30-Jul-2007 at 7:51am

>> That means making sure your problem merits a solution of the complexity you're undertaking. <<

Greg, by all means. I was really just asking if the linking mechanism between the Persistence Manager -> BO -> UI was available [ asking as a newbie], for purposes such as fixing this DGV bug... or other more useful things.

Thank you for your response.

Mike

Posted By: GregD
Date Posted: 30-Jul-2007 at 10:14am

Gotcha. Most welcome!

Greg

Print Page | Close Window