Subject | Re: [IBO] Re: cache sync - before edit |
---|---|
Author | Harald Klomann |
Post date | 2002-12-04T09:05:56Z |
Frode,
for me, (and I think for a lot of other users as well)
it´s the best to make no change in this behavior, because
it works as well as it could.
If you need a special handling as you described, just make
your own descent of TIB_Query which is able to handle your needs.
This is really not a big task, just a few lines of additional code
in the beforeEdit will do.
Harald
pi3k14 schrieb:
for me, (and I think for a lot of other users as well)
it´s the best to make no change in this behavior, because
it works as well as it could.
If you need a special handling as you described, just make
your own descent of TIB_Query which is able to handle your needs.
This is really not a big task, just a few lines of additional code
in the beforeEdit will do.
Harald
pi3k14 schrieb:
>
> If I were to specify a solution it would be something like this:
>
> * if cache sync didn't bring in an updated row everything should
> perform as normal
> * if cache sync did bring in an updated row there should be an
> option to alert the user and let him review the data before any edits
> are performed. Any selects should be canceled if the cached data for
> the field changed (because the selected data doesn't exist) and
> toggles/booleans should behave natural (ie. an unselect checkbox
> should become selected even if the new cache data show selected).
>
> If you for instance have BLOB fields that support drag and drop the
> GUI designer should turn on the warning option so the user can decide
> if he want's to review the original before the new image is pasted.
> (If that is a concern in the actual implementation).
>
> sincerely
> frode
>
> --- In IBObjects@y..., "Marco Menardi" <mmenaz@l...> wrote:
> > I subscribe what you said, but just to consier what can happen,
> let's
> > think about this situation:
> > you use tab and enter the NAME field, and you see "JASON". In the
> > database it's now "MARCO". The IB_Edit content is selected, so as
> soon
> > as you start typing it's erased.
> > This way with autoedit you will never see "MARCO". Without Autoedit,
> > as soon as you press "edit" you see "MARCO" appear, so you can
> choose
> > to continue editing or not.
> > But the autoedit behaviour you are requesting would solve problems
> for
> > other fields, so if not a 100% solution, it would be a 90% solution
> > much better than the 0% solution we now have.
> > Just some thoughts...
> > regards
> > Marco Menardi
> >
> > --- In IBObjects@y..., "pi3k14" <frode@a...> wrote:
> > > Agreed these are troublesome situations, but I can't see any of
> these
> > > justifying the fact that AutoEdit doesn't update the (windows)
> field
> > > that initiates the AutoEdit before it applies the key pressed.
> > >
> > > The user will always observe that something went wrong, and have
> the
> > > possibility to correct it.
> > > As it is now, he have no way of knowing that he just erased some
> > > important information (in a text field).
> > > That is BAD.
> > > The situations described below are ANNOYING.
> > > (sorry for yelling, but I just had to get out my feelings ;)
> > >
> > > sincerely
> > > frode
> > >
>
>
> ___________________________________________________________________________
> 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/