> (I'm resisting) If the interface does not allow the user to to his
> job quickly and easily, then that is a bad interface.

We agree on that point.

> If it goes against c/s theory, then so be it.

Well, that isn't so in my case. My users resisted a little at first so I
made it behave either way and they could chose. But, I made sure they
understood how to use the search mode for client/server friendliness. Guess
which method they use now? It's a no-brainer when you finally see how much
easier it allows the users to do what they need to do.

The point is, no user should ever be presented data they don't have an
expressed interest in. It's really trivial to use search mode with IBO to
insure that.

> 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.

I'm not saying you can't use grids. I'm just saying that datasets should be
refined with criteria so that the only records in the grid are records of
interest.

> 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.

If the BDE is doing something better than IBO does for you then there is
something wrong with the way you are using IBO. Perhaps you could share more
details about what it is you are doing. What version of IBO you are on, etc.

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

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


> Jason
>
>
> 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
>
>
>
___________________________________________________________________________
> 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 !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>