--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> At 06:21 PM 8/11/2007, you wrote:
>
>
> >OK I accept your answer for the second question. What about the
> >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.
>
> No, it's a question of using the control for its designed purpose.
>
> >I must say it's quite a mission with IB objects to set up what

should be as

> >easy as the DBLookupCombo with listsource.
>
> With 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.

>
> >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
>

I went thru the walkthru by Lars George, in fact that was before I
posted this question. Just a quick mention that the walkthru talks
about Property KeyLinks (PRODUCETYPE.TYPE=PRODUCE.TYPE) but if you
login as the owner of PRODUCETYPE then you have to say
TYPE=PRODUCE.TYPE on the keylinks property otherwise it refuses to
work. Very frustrating to debug this. This is why I say it is not
intuitive - if PROD owns PRODUCETYPE and PRODUCE then why can't you
always use the "Schema <dot>" in front of the table?

Anyway, using this walkthrough, I still cannot do what I want this
IB_LookupCombo to do. It should be the easiest thing to put two
fields into the display of the IB_LookupCombo but no matter what I
do, the second field refuses to display. It displays only in the
popup of the IB_LookupCombo. I hope someone can understand this
dilemma otherwise I will have to write my own lookup component which
kind of defeats the purpose of using IB Objects.

Thanks Helen for the wealth of information, and I appreciate your
time, but I still don't have an answer for my original question. And
yes, I did go thru the help file and the walkthrus. The
IB_LookupCombo works, it is just this one irritating aspect I can't
get right.
Shanil