Based on my experience, bad client/server design usually is also bad user
interface design. I know you are going to resist this but it is true.

What you need to do is couple your pick grid along with the search mode.
Then, the user quickly types in some simple criteria and fills the grid with
just a few records to select from instead of thousands. It's very fast,
direct and efficient and puts the burden on the server and not the sifting
power of user's eyes.

Once they were to get used to being able to do that they will discard the
method you are referring to like a dirty night shirt.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "stanw1950" <stanw@...>
To: <IBObjects@yahoogroups.com>
Sent: Friday, February 22, 2002 8:43 AM
Subject: [IBO] Re: tib_grid performance


> Thanks for the response Marco. Basically the solution is - it hurts
> when I do that so don't do that.
>
> In our situation there are many times where a user is at a part
> number (for example) and wants to get to a similar part number
> quickly. He doesn't want to click next or prior until he finds it and
> he doesn't want to start typing part of the part number until he
> finds it because he may not know exactly what the part number is. By
> seeing a grid with many part numbers (and their attributes), he can
> scroll around quickly until he recognizes the correct part number
> (based on the attributes) and just have to click on it in the grid to
> make it current. Also, our application is such that if the user is at
> an order in the order screen (for example) and clicks to the part
> screen, the part that was on the order is made the current part in
> the part screen (with a locate). It may be the last part in a 30000
> part table.
>
> I'm not saying that this is not bad C/S design, but I can't tell the
> users that we can't do it like that anymore because it's bad C/S
> design. They'll say that's B/S. I want to eliminate the bde, so I'll
> keep trying. Thanks again.
>
> Stan Walker