Subject | Re: IB_LookupCombo |
---|---|
Author | Shanil Misra |
Post date | 2007-11-08T12:24:45Z |
--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@...> wrote:
data DRIVEN. This is conceptually opposite to your idea, based on
TDatasource and the data-AWARE controls that hang off that.
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.
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.
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.
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.
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
>should be as
> 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
> >easy as the DBLookupCombo with listsource.that their behaviours are driven directly from the data. They are
>
> With the IB Objects CONTROLS (note this word) you must understand
data DRIVEN. This is conceptually opposite to your idea, based on
TDatasource and the data-AWARE controls that hang off that.
>have syntax specific entries.
> >This one requires a whole lot of not-so-intuitive settings to
>They are designed to represent specific concepts in a relational
> The IB_ controls are *not* designed to mimic the VCL controls.
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.
>some key value representing, typically, a type or a member of a
> You will have a parent set that has in it a column that stores
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.
>something like
> A typical Keysource-lookup set (looking at a simple case) would be
>relationship here, where one parent record subtends 0 to many child
> 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
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.
>properties because it is bound to *two* datasets.
> The control itself has twice the normal number of data-related
>keys in the relationship
> 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
> 4. Displayfield that you select from amongst the lookup set'sfields to display in the upper part of ib_lookupcombo.
>things you can do, including embed this lookup into an ib_grid
> Those are the basics for your setup, although there are more
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.
>in one of those TechInfo sheets.
> As I said yesterday, you will find a walkthrough of setting it up
>I went thru the walkthru by Lars George, in fact that was before I
> Helen
>
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