| Subject | Re: [IBO] IB_LookupCombo |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-11-08T09:55:18Z |
At 06:21 PM 8/11/2007, you wrote:
You will have a parent set that has in it a column that stores some key value representing, typically, a type or a member of a range. On the parent record you store the key value. In another table, you store the entire range of keys and associated descriptions. The relationship between the stored key on the parent record and the descriptive record in the other table is a "Keysource-Lookup" relationship. Its setup is closely linked (via properties) with the parent set. The data linkage is made between the key value of the lookup set and the matching key value of the parent.
A typical Keysource-lookup set (looking at a simple case) would be something like
In the parent, you might have
select field1, field2, ..., atype
from parent
The atype field is the key to a lookup set:
select id, description
from atype
order by description
The lookup set must have unique keys.
Note we are NOT talking about a parent-child or master-detail relationship here, where one parent record subtends 0 to many child records. You'll come unstuck if you try to use it to present an editing interface for a master-detail relationship. This relationship is inverted: one lookup record can be used by many parent records.
The control itself has twice the normal number of data-related properties because it is bound to *two* datasets.
On the lookup set, you set
1. Keysource that points to the ib_datasource of the parent set.
2. Datasource that points to the lookup dataset's ib_datasource.
3. Keylinks of the form lookupkey=keysourcekey to bind the two keys in the relationship
4. Displayfield that you select from amongst the lookup set's fields to display in the upper part of ib_lookupcombo.
Those are the basics for your setup, although there are more things you can do, including embed this lookup into an ib_grid containing the parent records. (In fact, embedding it in a grid is the way most people use it) and tying a subquery expression in the parent set specification to the description field in your lookup set.
As I said yesterday, you will find a walkthrough of setting it up in one of those TechInfo sheets.
Helen
>OK I accept your answer for the second question. What about theNo, it's a question of using the control for its designed purpose.
>first question? It does not make sense that the popup allows the
>two fields, but the display does not. I am sure it's a little
>matter of populating one of the component entries correctly.
>I must say it's quite a mission with IB objects to set up what should be asWith the IB Objects CONTROLS (note this word) you must understand that their behaviours are driven directly from the data. They are data DRIVEN. This is conceptually opposite to your idea, based on TDatasource and the data-AWARE controls that hang off that.
>easy as the DBLookupCombo with listsource.
>This one requires a whole lot of not-so-intuitive settings to have syntax specific entries.The IB_ controls are *not* designed to mimic the VCL controls. They are designed to represent specific concepts in a relational database. It should become "intuitive" for you when you understand the notion behind the particular control. The IB_LookupCombo specifically is not designed to provide some idiomatic "pretty box" for packaging a set for editing. It is purpose-designed to provide a dynamic mechanism for one particular kind of relationship, referred to as a "Keysource-Lookup" relationship.
You will have a parent set that has in it a column that stores some key value representing, typically, a type or a member of a range. On the parent record you store the key value. In another table, you store the entire range of keys and associated descriptions. The relationship between the stored key on the parent record and the descriptive record in the other table is a "Keysource-Lookup" relationship. Its setup is closely linked (via properties) with the parent set. The data linkage is made between the key value of the lookup set and the matching key value of the parent.
A typical Keysource-lookup set (looking at a simple case) would be something like
In the parent, you might have
select field1, field2, ..., atype
from parent
The atype field is the key to a lookup set:
select id, description
from atype
order by description
The lookup set must have unique keys.
Note we are NOT talking about a parent-child or master-detail relationship here, where one parent record subtends 0 to many child records. You'll come unstuck if you try to use it to present an editing interface for a master-detail relationship. This relationship is inverted: one lookup record can be used by many parent records.
The control itself has twice the normal number of data-related properties because it is bound to *two* datasets.
On the lookup set, you set
1. Keysource that points to the ib_datasource of the parent set.
2. Datasource that points to the lookup dataset's ib_datasource.
3. Keylinks of the form lookupkey=keysourcekey to bind the two keys in the relationship
4. Displayfield that you select from amongst the lookup set's fields to display in the upper part of ib_lookupcombo.
Those are the basics for your setup, although there are more things you can do, including embed this lookup into an ib_grid containing the parent records. (In fact, embedding it in a grid is the way most people use it) and tying a subquery expression in the parent set specification to the description field in your lookup set.
As I said yesterday, you will find a walkthrough of setting it up in one of those TechInfo sheets.
Helen