Mel:

You will struggle trying to do it the way you are approaching it. A lstListNavigator will not work correctly when the columns reference data from *separate tables*. The columns must all come from the same table/cursor in the *source workarea*. This type of control builds a separate cursor based on the source workarea specified using USE AGAIN so, the data in the list is actually coming from a different table at runtime to the one you actually specify. That's why you can/should only use a field name in the display expression - because at design time, you have no idea of the cursor name that the control builds as its display source at run time.

The best way to achieve your display is to use a view (or Sql-Select query generated cursor) as the record source for the listnavigator where the view (or Sql-Select) query selects the data from the child and grandchild tables and puts the values from the two tables into the single view/result cursor.

The other way you can tackle this is to use a grid as the navigator. If you want to do it this way, come back to me for some more details but essentially, the grid's record source would be the child table. Then, the column source for the grandchild data is actually a form method that does a SEEK on the grandchild table and returns the value you require as the column source for each row in the grid.

Anyhow, digest this information and if you want to avoid using a view and a standard listnavigator, I can help you out setting up the same thing but with a grid.

HTH