--- In IBObjects@y..., Geoff Worboys (TeamIBO) <geoff@t...> wrote:

> > I think I'm correct in saying that the default TIB_Query setting

of

> > RefreshOnParamChange = true, causes the RefreshAction setting to

be

> > ignored. Could this be changed? (V4.2.Fp)
>
> It should not cause RefreshAction to be ignored - although given

that

> the result set is presumably completely changed, any other action
> than Open is probably unreliable.

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.

> > Given that there is a certain amount of extra code (BeginUpdate(),
> > EndUpdate())to be written when using RefreshOnParamChange and you
> > only want one refresh to occur (when changing multiple params,

this

> > would be the norm, I'd imagine), it seems simpler to have
> > RefreshOnParamChange default to false, use a TIB_Query->Refresh()
> > call when needed, and keep the benefit of the RefreshAction

setting.

> > Or have I missed something again?
>
> It may help if you explain exactly what your problem is. How are

you

> changing parameters?
>
> RefreshOnParamChange does nothing with BeginUpdate/EndUpdate itself,
> when it is turned on every parameter change event will result in a
> refresh. If you want to change multiple parameters at a time you
> should provide the BeginUpdate/EndUpdate yourself.

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(). 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!

Cheers,
Steve