|Subject||Re: [IBO] Re: IB_LookupCombo|
> I went thru the walkthru by Lars George, in fact that wasI do not understand what this is about... but then I never have
> 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?
tables owned by different users. You cannot expect a lookup to
work unless the user has sufficient access to both tables
involved in the relationship, other than that the table.field
notation has always worked for me (there could be alias issues
with FBv2, which I imagine means using alias.field).
As for "schema <dot>" this notation does not (yet) work for any
Firebird database. It has been discussed in the architect list
but AFAIK there has been no progress on that front.
> Anyway, using this walkthrough, I still cannot do what I wantIB_LookupCombo behaves like a ComboBox in csDropDown style,
> 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.
where it is possible to type into the display/text area. Such
typing allows the incremental search/lookup feature - type
"Wor" to jump all the way down, past perhaps thousands of rows,
to the words starting with "Wor". However such typing also
means there are limits on how you can use the display area, for
example arbitrary splitting into columns for additional field
display would not be practical (given the Windows API).
Note however that there are two ways of showing the additional
field from the lookup - NOT in the ib_lookupcombo, but in a
. connect a TIB_Edit or TIB_Text to lookup datasource/fields
Simple enough, you will almost certainly want to make
the lookup dataset read-only to prevent it accidently
going into edit mode, probably set TabStop to false on
the TIB_Edit if you dont want ti part of the edit seq.
. use a join in the main dataset and the KeyDescLinks in
the lookup dataset. This is just like using KeyDescLinks
for the name/lookup field but you use it for additional
fields. You need a join rather than a subselect in the
main dataset for efficiency, but that also means defining
the main dataset KeyRelation and so on.
There is yet another way in which you may want to use multiple
fields in a lookup. Given the table of Australian suburbs and
I found it necessary to create the unique lookup index on both
the NAME and POSTCODE fields (as the same suburb-name may
appear in different postcodes, and some suburb-names have the
To achieve this with TIB_LookupCombo it would be necessary to
create a duplicate field (whether it needs to be a real field
or only a computed field depends on various factors, note that
new versions of Firebird support expression indexes - see the
FB v2 release notes - but I have not used that to know how well
it works in this situation). eg:
LOOKUP_NAME COMPUTED BY (NAME || ', ' || POSTCODE)
Now it is possible to use LOOKUP_NAME instead of NAME and so
have two columns inside the display (albeit using the ','
delimiter rather than a column like display).
My own lookup control variation:
has special support for the above scenario but may be redundant
now that Firebird has expression indexes.
If none of the above suggests help then feel free to go ahead
and write your own. I wont bother to wish you luck, the ONLY
way to get a lookup working is with LOTS of hard work.