> I think I can see what you're saying, but in one of my grids the
> query is filtered, or not, by external actions that change the
> parameters fed to its' select proc. If I have, say, just one row
> showing & focused because of the filtering, and then reduce the
> filtering by changing the parameters so that I get more rows
> showing, then when using Refresh() & raKeepDataPos, the previously
> focused row stays focused as more rows return. But if I try this
> whilst relying on RefreshOnParamChange, then the first row always
> becomes the focused row.

Without more investigation all I can say that it does not appear (from
the code) that RefreshAction is being ignored as such, there must be
some other factor involved.

Do you have any mastersource involved? That could certainly have
impacts over the order in which things happen. There are several
other possibilities I think, but I would need a demo app to see
exactly what you want to achieve.

> I used the standard code you provided last week for BeginUpdate /
> try / __finally / EndUpdate etc, and while it all works, it does
> seem to have this problem respecting the RefreshAction setting, as
> I've described.

> I have no big problem with using Refresh() after changing the
> parameters instead, but I wondered why the other way was better (&
> the default), and if there would be a penalty of some sort that I'd
> just have to live with, (unless the RefreshAction problem could be
> fixed). I'm sure there's a very good reason why it's used so much in
> Jasons' code, rather than using Refresh().

I am happy to take a detailed look at the RefreshAction problem if you
can send me a demo (perhaps based on the employee.gdb or on one of the
IBO sample databases).

If you would rather just work around the problem I have some
suggestions...

Try it with RefreshOnParamChange turned off and then doing your own
explicit Refresh. If that does not do it then you can replicate the
KeepDataPos capability yourself...

var
CurRec: string;
begin
CurRec := IB_Query.Bookmark;
<< param changes and refresh or whatever >>
if CurRec <> '' then
IB_Query.Bookmark := CurRec;

And that reminds me, you do have KeyLinks defined for this query?
(Maintaining the specific row requires that there are keylinks, or for
simple, not joined, selects a primary key that IBO can discover for
itself.)

> On the other hand, while I like to know if I'm wrong, maybe it's not
> worth worrying about too much. Life's too short!

Unless it is a KeyLinks problem I suspect you have found a genuine
problem. Whether you want to help track it down or just avoid it is
upto you.


--
Geoff Worboys - TeamIBO
Telesis Computing