Jason

(I'm resisting) If the interface does not allow the user to to his
job quickly and easily, then that is a bad interface. If it goes
against c/s theory, then so be it. I have a feature that works fine
with bde and not so fine with ibobjects, and so evidently I have to
change the feature. For the problem screen, it probably won't make
much difference. But there is one screen in our application where the
user must see many records at one time. It shows all the work for the
user's department. The table itself has all the outstanding work for
all the departments. Managers filter by department to see whats going
on. They don't necessarily care about the fields, but they do want to
see everything in one glance. Users look to see what job they should
do next. Rows are color coded depending on various statuses. This
must be a grid. Your solution for my current problem is good, and I
will try it, but it won't always work. I know it would be easy just
to say "ok stick with the bde", but I don't want to do that (even if
some users will suffer a little). Anyway, thanks for your help and
suggestions.

Stan Walker

--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> 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@e...>
> To: <IBObjects@y...>
> 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