Hi Gediminas,

> Paul, it's working - almost as I wanted. If I KeyDescLinks left
> blank during design and set value dynamicly (when running) - columns
> will be updated?

I don't know, never did that. You can try it out, but why would you
want to do such a thing? Normally you know at design which field you
want to show to the user as a name or description.

> can I use IB_ListBox instead IB_LookupList in the DancesLookup
> query?

Not with a lookup query. IB_ListBox contains fixed lookup values that
you must put there yourself (as TStrings) so it makes a lookup query
unnecessary. In your case, you'd attach the IB_ListBox to
srcClassDancesDet, and set the DataField to Dance_ID.

Now, how to get the values in the IB_ListBox?

- If your collection of Dances never ever changes, you can fill them
in at design time, just like with a regular ListBox. In your case,
you'd fill in the Dance_IDs in the ItemValues property and the Names
in the Items property. So the user sees the names, but when he
clicks one, the corresponding Dance_ID is assigned.

(Should the Dances change one day, you'd have to edit Items and/or
ItemValues, and rebuild the app!)

- If the Dances may change from time to time, make a TIB_Cursor
selecting Dance_ID and Name from Dances. Upon program start, loop
through the cursor to fetch all the values and load the ListBox's
Items and ItemValues from them. I do that sometimes, starting the
loop like this in BCB (you don't need to Open the cursor):
for ( MyCur->APIFirst(); ! MyCur->Eof; MyCur->APINext() )
{
// assign values...
}

- If the Dances may change while the program runs, you'll have to
signal that one way or another and re-loop the cursor.

As you can see: this requires a lot more setup work on your part -
work that a Lookup Query does automatically for you! But the advantage
of an IB_Cursor + IB_ListBox is that these are less heavyweight
components; they require a little less memory, and they will execute a
little faster _if_ your Dances almost never change.

> Also looking for a bank :-D

On your own risk! :-)


Greetings,
Paul Vinkenoog