Hi Jason,

I think the problem is also hitting at other times (scrolling
through the master dataset and so on), but closing was the one
I could see and reproduce most easily, so that was the one I
chose to debug first.

It turns out that there is a combination of things going on
here. The reason why it showed so badly on close is that there
are three datachange events generated by close, one each from
these TIB_Statement.SysUnprepare lines:
ProcessLinkEvent( setFieldsRefsChanged, 0 );
SysLayoutChanged;
SysPreparedChanged;

The example table had three user-name comboboxes, so that's
3x3x600 (5400) name matches that result.

Then add to that: In the older version of my application (used
FB v1.5) the user list was a simple sorted stringlist so name
lookups were fast. With this new version I'm using Windows
trusted authentication and that required that I implement
surrogate keys for user names (so that a changing Windows logon
could still be matched to the same underlying audit data).
This means that my user lists now look like:
Name=Key

Name lookups are fast, but datachange events require a match
to the key, and that is a brute force search, hence the problem
showed up only now.


I can probably resolve the close problem by simply having the
control SysDataChange check the field reference on the datalink
directly, and when no longer assigned use ItemIndex := -1 to
clear it (instead of, as it is now, trying to match a blank
string against 600 items).

But to solve the scroll problem I am going to have to create a
sorted stringlist to enable fast lookup of the key values.
(If I was already using newer Delphi I would implement a
dictionary solution to the problem.)


Some of this may beg the question: Why am I using a combobox
for such a long list, instead of a proper Lookup control?

Well, this is a 15 year old application, there weren't 600
users in the list back then. And I use a lot of user-name
fields (who created/updated records on most tables and so on).
It seemed, back then, that comboboxes were the most efficient
way to do it (since the list of users doesn't change that
often, having the list updated only when the user logs on has
always been good enough). Changing all the forms over to
lookups now is going to be harder than optimising the combobox.

PS. I'm using my TIB_ComboBoxEnh control, so I can do all that
without touching the IBO code. It appears that TIB_ComboBox
would be _slightly_ more efficient than my control in this
regard because the values are already in their own list - the
list isn't sorted, but at least you don't have to pull the
name=key value apart before you do the comparison.


At least the hard part is now over: I understand the problem.
It's taken me a long time to get to this point, the rest is
just code. :-)

--
Geoff Worboys
Telesis Computing Pty Ltd


'IBO Support List' supportlist@... [IBObjects] wrote:

> Geoff,

> That's interesting that it shows up when the form is closing.
> Is there some way you can have it ignore doing that work since
> it is closing up? Is there some kind of inefficiency that can
> be corrected? Seems to me this should be able to be worked out.

> Feel free to keep us posted.

> Thanks,
> Jason Wharton
> www.ibobjects.com