> Hello Jay,
>
> At 04:42 PM 13/07/2005 -0500, you wrote:
>>I have uploaded the sample application, database and images of the problem
>>I
>>am having (Lookup_Err_Sample.zip).
>
> OK, I had a play with your sample app. It will probably be easiest to go
> through your readme.txt and discuss each issue....
>
> The sample shows the problematic behaviour I am having with the lookup
> combo. I am currently using Delphi 7 with IB Objects 4.5.Ai. The included
> images are screenshots of the behaviour I am having.
>
> The grid that is having the problem is the on on the "Productos page".
>
> The general idea of the program is to be able to specify the products that
> are valid for a given supplier. The program is for editing the supplier
> and
> to be able to consult and modify the products that are allowed to be
> purchased from the specified supplier.
>
> The behaviour I am getting is the following:
>
> 1) The PROVART grid display the code CVEART and the description NOMPROD
> correctly.
>
> Yes. Although I had to comment out your uses of the Jedi VCL controls as
> I
> don't have them installed.

Sorry about that, I eliminated all controls of other 3rd party controls but
aparently did not delete them from the uses clause.

>
> 2) When I click on the NOMPROD field on the grid, the lookup (arrow)
> button
> appears and the field contents become <blank>, (blue) no text.
>
> Yes, that is as expected. The normal use of this control is to supply a
> lookup value. As soon as you click the control, the record goes into Edit
> mode and prepares to receive the new value. The value that is displayed
> in
> Browse mode is, of course, a derived field so, as soon as the record is in
> Edit mode (and the key value is going to change) that derived field
> becomes
> invalid.
>

In all applications (mine or others) the original value in a lookup control
or any other control is kept an it may or may not be changed. The normal
behaviuor of all other lookup combos I have use is that the original value
is kept ant when the lookup box is opened, you are positioned in the list
exactly on the original value and from there you may navigate the list to
make the change.

The behaviour I am getting is as if there is no value and you have to start
from scratch, not very user friendly at all.

> A valid value will appear again *after* the change is committed. At that
> point, the dataset will requery the dataset and get the new value into the
> derived field.
>

> This makes this a not-very-pretty interface to implement what you are
> implementing, which is not a lookup, but a master-detail
> relationship. (The so-called "lookup table" is *really* a master to the
> intersection set/table PROVART!)
>

I assume that I did no make very clear the purpose of the PROVART table so I
will try to clarify it.
The master table is PROV01 which has the information of suppliers. For each
supplier, the PROVART has a list of the articles (products) that can be
purchased from the particular supplier. PROVART is in fact a detail table of
the master PROV01 (sippliers). For example, if IBObjects is a supplier, I
will only purchase IB components from them and not computers, supplies,
cars, telephones or any other products. In a purchase order module, when I
want to select the product to purchase from IBObjects, only the IB
components will be available instead of a lookup of the entire prodcut list
which may contain thousands of records. The PROVART table really contains
the list of products available by any given supplier. The CANTPEND field you
mention later on is to hold (and display to the user) the pending units that
have been ordered but have not been received.

If IBObjects sells other products (for example other printers), I may want
to add those products to the list available by IBOjects. I would then add a
record to PROVART (For IBObjects only) and then I would have to lookup the
product (printer) from the entire product table (may be thousands of
records).

I think that under this scenario, the table INVE01 (Art) is in fact a lookup
table of PROVART. I hope all this helps.

> 3) I click on the arrow button and a grid of the lookup table appears with
> the values of the code (CLV_ART) and the escription (DESCR), but at the
> beginning of the table and not at the current value of the PROVART table.
>
> Yes. That seemed to be due to your custom popup. To fix this, I did the
> following:
>
> i) set the productos grid temporarily to alNone and made some room beside
> it.
> ii) deleted your ib_lookupcombo (cbArt).
> iii) clicked into the spare space created beside the grid and dropped a
> fresh ib_lookupcombo into it, naming it cbArt, as before
> iv) set the datasource property
> v) Cut (Ctrl-C) the ib_lookupcombo out of the spare space, clicked on the
> grid, and then pasted (Ctrl-V) the ib_lookupcombo into the grid
> vi) Then set the grid's alignment back to alClient.
>

I tried your suggestion and I still get the same wrong behaviour. On step
(v) I assume I am to use (Ctlx-X) instead of (Ctlx-C) because otherwise the
original control appears out of place. I tried both ways but still the
lookup does not work as expected.

I can't believe that a simple lookup operation can not be accomplieshed in a
straight forward way. I had high hopes (and assumed) that the IB_ components
would work properly and am appaled that with such a long history and so much
great work (very complicated) in the internal working which appear to
function flawlessly (transactions, updates and such), the actual user
interface components (IB_LOOKUP) and (cusutom popup grid) don't work to the
bare minimum expectations. This has me completely baffled and I can't
believe that this is so, it is completely ilogical. There MUST be something
wrong in the way I am doing things, and the lack of a good samples doesn't
help much either. I can't find a sample with the basic common usage of a
lookup combo.

I will describe a simple sample that would be helpful:

A grid of products that has the fields ("Code", "Description", "Category
description"). The "Category description" is actually a description of the
actual category code stored in the table. Be able to order the rows by any
of the 3 fields ("Code", "Description", "Category description"), and be able
to edit the 3 fields with the edit of "Category description"being a lookup
to a CATEGORY table.

To me this is very basic and common and is essentially the same concept of
what I am trying to do.

> Another quirk is that the first time that I open the lookup grid, it
> appears very narrow. If I close it and open it again, it appears with the
> correct width but still not at the value of the data.
>
> Again, this quirky behaviour was caused by your custom popup. The fresh
> ib_lookupcombo responded properly to the FieldsDisplayWidth property that
> was set in the field properties.
>

Even if I do not use the custom popup (I also tested that a lot of times),
the list appears from the beginning instead of being positioned at the
current value.

> I didn't attempt to fix your custom popup. It didn't seem to do anything
> desirable so it wasn't worth wasting my time on it.
>

Since the products table (lookup table) is large, the purpose of the custom
popup is to be able to order the products either by Code or description
(clicking on the header) and do a search on either field accordingly.

> I have dedicated HOURS at this and cannot get it to work right. What am I
> doing wrong?
>
> Some things I would recommend --
>
> a) Pay attention to your connection and transaction properties. You had a
> mish-mash there which appeared to be starting default transactions. I
> don't know what you intended for ib_trans, but I would have selected it as
> the DefaultTransaction for the connection. Also, you had some
> discrepancies that seemed to have been caused by hard-setting the
> DatabasePath properties around the place, instead of using (selecting) the
> IB_Connection property.
>

I am really probably doing things completely wrong in this area since the
whole transaction subject is still very fuzzy to me. In the real
application, the first screen (delphi form) established a connection and a
menu is displayed where all subsequent forms will be opened. All other forms
will be using the same connection (from the menu form) to avoid making
multiple connections.

On each form, I want to use a diferent transaction so if the user has
several forms open and does a commit on a particular form, it will only
apply to the changes made to that specific form and not to all open forms.
Am I completely wrong? or is there a better (cleaner) way of accomplishing
this.

The IB_QUERY components should ALL make a reference to the IB_CONNECTION
component. When I do that, the databasepath is automatically set (not by
me). Is that normal?

> b) Maybe I'd want to rethink the UI for those two master-detail
> relationships, since the embedded lookupcombo is (at least in my opinion)
> quite ugly for this task and it's not immediately obvious how it works.
>

I hope the previous explanation clarifies this for you.

> You have an associated problem here, that some of the descriptions are
> actually blank. Again, this is manageable in a more conventional
> master-detail interface but quite unfriendly to the user in this
> lookup-style interface.
>

Remember this is only a test database and not all the data is correct.

> c) As the demo currently stands, you can't create new PROVART records
> because you haven't taken care of defaulting the non-nullable column
> CANTPEND. You either need to bring it into the dataset and apply a
> default
> to it via FieldsDefaultValues, or fix the metadata so that a default gets
> written one way or another.
>

Do understand that I am starting to use the new IB components and this
sample is incomplete. I even eliminated ALL code from my original program
to try avoid confusion so that whoever analizes the problem does not have to
search through a lot of unnecesary code. I eliminated the code of the
OnNewRecord event that takes care of setting default values.

> d) I strongly recommend that you restrict the PROV01 set for displaying
> it
> in a grid.. It is plainly ridiculous to do select * from PROV01 and have
> to manage 40 columns in a grid on a page control. If you want to edit
> these records, show a few identifying fields in the grid and provide a
> single-row edit layout alongside, using a shared datasource for the grid,
> the edit fields and the bar controls.
>
> Helen
>

The "Detalle" page (and some other pages) will be displaying the complete
information of the other fields of the PROV01 table and the user may also be
navigating the table looking at the complete information.

In a slow connection environment I totally agree with you, but for user
convenience and taking into consideration that the table is not extremely
large (no more than 500 suppliers), there really is no performance
degradation by doing things this way.

>
>
>
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
> InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
> papers,
> keyword-searchable FAQ, community code contributions and more !
> Yahoo! Groups Links
>
>
>
>
>
>
>
>