BindingSource:RefreshAll() - Suppress Position getting reset

Posted by Lieven De Foor on 05-Mar-2018 08:35

Somehow my post got deleted while editing, so reposting again...

When calling the BindingSouce:RefreshAll() method, the current Position seems to get lost and reset to 0.

Is this intended behavior? Can it be suppressed?

I'm currently creating a custom BindingSource which has SuspendPositionChanged/ResumePositionChanged methods so I can suppress any listeners from getting the event when calling RefreshAll + reset original position, but not having the position change at all would be even better.

Anyone from Progress can comment on this?

DEFINE VARIABLE BindingSourcePosition AS INTEGER NO-UNDO.

BindingSourcePosition = BindingSource:Position.

BindingSource:SuspendPositionChanged().

/* Change the data here... */

BindingSource:RefreshAll()

BindingSource:Position = BindingSourcePosition.

BindingSource:ResumePositionChanged(). /* And nobody noticed a thing... */

Laura Stern replied with:

Yes, this is done on purpose.  When you call RefreshAll(), it is generally because the set of records has changed.  So the current position may either no longer correspond to any row at all, or it may correspond to a different row than before.  So maintaining it, in the general case, doesn't really make any sense - to me anyway!  

Why are they calling RefreshAll()?

My answer to that was:

We have a grid (backed by a BindingSource bound to a query on a temp-table) where you can multi-select records and apply an operation on them. This operation executes on the AppServer and returns a temp-table of changed records. These changes are then copied over the client temp-table and the UI is refreshed by calling RefreshAll().

Since the query result set doesn't change, we don't need to reopen the query and RefreshAll() is sufficient.

But after the call to RefreshAll(), the active row is now the first row instead of the original one...

Posted by Laura Stern on 05-Mar-2018 10:26

So you mean the data in the selected rows change, but the records are always  the same.  OK.  So we'd need a different Refresh method to accomplish this.  They can put in for an enhancement request, but I don't really see that happening.

In the meantime, looks like they've solved the problem.  Though I don't know if they really need the inherited BindingSource.  That may be more expensive than another solution.  They could just set some local flag to tell them to ignore the PositionChanged event, and then reset the flag and Position property after calling RefreshAll.  Up to them.

Posted by Laura Stern on 06-Mar-2018 07:54

Yes, it's just that it's a hybrid.  For hybrids we have to emit code to generate a class type in .NET.  And depending on what they override, those calls would be a bit more expensive as well.  But I'm probably overly sensitive about all that!  I don't think they would notice any performance effect.

Yes, they could create an inherited version in .NET.

I was just pointing out that while making a child class might be the more elegant solution, it seems unnecessary.  But it really is up to them.

All Replies

Posted by Laura Stern on 05-Mar-2018 10:26

So you mean the data in the selected rows change, but the records are always  the same.  OK.  So we'd need a different Refresh method to accomplish this.  They can put in for an enhancement request, but I don't really see that happening.

In the meantime, looks like they've solved the problem.  Though I don't know if they really need the inherited BindingSource.  That may be more expensive than another solution.  They could just set some local flag to tell them to ignore the PositionChanged event, and then reset the flag and Position property after calling RefreshAll.  Up to them.

Posted by Lieven De Foor on 06-Mar-2018 02:35

Exactly Laura.

Could you elaborate a bit on the expensiveness of inheriting the BindingSource?

Is this because inheriting creates a hybrid class, which is not the case when using it directly?

What are the performance penalties exactly?

Could we create an inherited version in .NET instead?

We were already using an inherited, extended version, so at least in our case things won't get worse than they already were...

And as far as submitting a feature request, I'm still adding one from time to time, but lost most motivation for that a while ago seeing how they get handled (or not handled...)

Posted by Laura Stern on 06-Mar-2018 07:54

Yes, it's just that it's a hybrid.  For hybrids we have to emit code to generate a class type in .NET.  And depending on what they override, those calls would be a bit more expensive as well.  But I'm probably overly sensitive about all that!  I don't think they would notice any performance effect.

Yes, they could create an inherited version in .NET.

I was just pointing out that while making a child class might be the more elegant solution, it seems unnecessary.  But it really is up to them.

This thread is closed