At 01:02 AM 26/03/2003 +0000, you wrote:

>Hi there,
>
>I asked this question a couple of days ago, but maybe I confused
>anyone who read it, as I got confused writing it!!
>
>When I change the value of a field in a grid (in code, not through
>GUI), which is linked to a lookupCombo, the combo is showing
>inconsistent results until something gets refreshed.
>
>I say "something" because if I refresh the query attached to the
>grid, the correct results are shown, or if I refresh the grid
>itself, the correct results are shown. This I can deal with, but my
>problem is that if I refresh either of these, the grid loses its
>focus.
>
>I don't understand why the grid loses focus from a simple refresh.
>
>It's like the tab-order gets restarted, as the field with the focus
>after refreshing is the first object in the tab order list.
>This is a nuisance, because the user will not have completed
>entering data into the grid, when the focus leaves the grid.
>
>Something to note though, is that if I hit the F5 key, the grid is
>refreshed properly (lookupCombo showing correct data) AND the grid
>keeps it's focus.
>
>Is there a way in code to simulate a simple F5 refresh? (Calling
>TIB_Grid.Refresh does work, but the grid loses focus)

So, are you calling Refresh on the grid, or the dataset?

As I recall, the action that you were doing was to change (in code) the
lookup key that was selected from the embedded lookupcombo. In doing that,
you invalidate the parent dataset row without the "knowledge" of the
lookupcombo - so you need to call refresh on the dataset to get the correct
KeyDescLinks in the description column that is being sub-selected by the
parent query.

By calling Refresh on the dataset, not only should the form's control focus
remain undisturbed, but you can specify that the current row and column
also remain the same, by using RefreshAction raKeepDataPos.

>This is very strange behaviour which I am struggling to understand.

Let the data do the work!! Just think of the controls as containers, which
will behave just as they should unless you add code that jumps into their
events and tries to make them behave differently...you can if you have to,
but you shouldn't if you don't have to.

Helen