| Subject | Re: [IBO] TIB_LookupCombo for multiple Lookup keys |
|---|---|
| Author | Helen Borrie |
| Post date | 2002-08-21T12:36:37Z |
At 11:50 AM 21-08-02 +0000, you wrote:
is that one live lookup table can't be bound to different keys
simultaneously, because the lookup "follows" the parent dataset when it
(the parent) scrolls.
When I'm using the same table for different lookups for the same parent
(i.e. different keys) I don't embed them in the grid and I don't Keylink
them. (But, then, I also avoid editable grids!)
I just position the ib_lookupcombo somewhere handy to all of the fields
that need to use it, with a "live" dropdown not bound to any particular
parent key. I'll typically have a borderless speedbutton with an ellipsis
alongside the captions of those fields, visible only in Edit mode.
The speedbutton's action in each case is to pick up any characters already
entered in the actual associated field and to call a procedure that sets
the Tag property of the lookup dataset to flag which lookup key is wanted,
drops down the lkpcombo and locates the nearest match. (I happen to think
this is a much more user-friendly interface than a drop-down in a grid,
anyway - people want to TYPE in editable grids, not click things; and a
grid that's packed with jazz at edit time (to me) does not simplify the task).
As soon as something in the lkpcombo is selected, I just have a line of
code that picks up its key and writes it into the lookup key column of the
parent that is identified by the Tag property....really just the way it
*would* work if the lookup dataset was bound to that key.
Also watch out for a response from Geoff on this question, because I think
he has a component that supports "shared key" lookup behaviour.
Helen
>One related question.You are if you want them to be "double data-aware". The reason of course
>
>If my customer table has 4 entries:
>
>Contact1
>Contact2
>Contact3
>Contact4
>
>which are all FK's into the contact table, it appears that in order
>to have 4 lookup combos listing all the contacts, I need 4 queries
>and 4 datasources to link up each combo.
>
>I naively thught I could just add
>
>contacts.contact_id=customers.contact1
>contacts.contact_id=customers.contact2
>contacts.contact_id=customers.contact3
>contacts.contact_id=customers.contact4
>
>to my contacts query keylinks. I was wrong.
>
>Am I forced to use a query and a datasource for each TIB_LookupCombo?
is that one live lookup table can't be bound to different keys
simultaneously, because the lookup "follows" the parent dataset when it
(the parent) scrolls.
When I'm using the same table for different lookups for the same parent
(i.e. different keys) I don't embed them in the grid and I don't Keylink
them. (But, then, I also avoid editable grids!)
I just position the ib_lookupcombo somewhere handy to all of the fields
that need to use it, with a "live" dropdown not bound to any particular
parent key. I'll typically have a borderless speedbutton with an ellipsis
alongside the captions of those fields, visible only in Edit mode.
The speedbutton's action in each case is to pick up any characters already
entered in the actual associated field and to call a procedure that sets
the Tag property of the lookup dataset to flag which lookup key is wanted,
drops down the lkpcombo and locates the nearest match. (I happen to think
this is a much more user-friendly interface than a drop-down in a grid,
anyway - people want to TYPE in editable grids, not click things; and a
grid that's packed with jazz at edit time (to me) does not simplify the task).
As soon as something in the lkpcombo is selected, I just have a line of
code that picks up its key and writes it into the lookup key column of the
parent that is identified by the Tag property....really just the way it
*would* work if the lookup dataset was bound to that key.
Also watch out for a response from Geoff on this question, because I think
he has a component that supports "shared key" lookup behaviour.
Helen