Subject | Re: [IBO] Re: More Scroll Questions... (More Info) |
---|---|
Author | Jason Wharton |
Post date | 2002-10-16T16:06:44Z |
Ok, I got this now, I hadn't seen this yet.
When doing a rollback it is sometimes necessary to do a refresh. I've tried
to make IBO intelligent about it, but there are just cases I cannot get away
from. Perhaps what you are saying here, which could be possible, is that I
am doing an operation internally that isn't necessary since there was
nothing posted prior to the call to Rollback.
I'll log this as an item to look into, but I advise you to make your program
work around this as a matter of principle. Doing a Refresh in response to a
Rollback just may be necessary in some cases.
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
-- We may not have it all together --
-- But together we have it all --
When doing a rollback it is sometimes necessary to do a refresh. I've tried
to make IBO intelligent about it, but there are just cases I cannot get away
from. Perhaps what you are saying here, which could be possible, is that I
am doing an operation internally that isn't necessary since there was
nothing posted prior to the call to Rollback.
I'll log this as an item to look into, but I advise you to make your program
work around this as a matter of principle. Doing a Refresh in response to a
Rollback just may be necessary in some cases.
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
-- We may not have it all together --
-- But together we have it all --
----- Original Message -----
From: "Eric Handbury" <ehandbury@...>
To: <IBObjects@yahoogroups.com>
Sent: Monday, October 14, 2002 3:38 PM
Subject: [IBO] Re: More Scroll Questions... (More Info)
> I have confirmed the situation where the behaviour outlined in my
> first post is happening:
> 1) I put the qrCustomer dataset into dssEdit mode.
> 2) I click on Commit which performs a CommitRetaining.
> 3) I put the qrCustomer dataset into Edit mode once again.
> 4) I click on Rollback which performs a RollbackRetaining.
> 5) The qrCustomer.Scroll Events are called. (Incorrect...)
>
> Without the first Commit, the Scroll events do not fire. As in:
> 1) I put the qrCustomer dataset into dssEdit mode.
> 2) I click on Rollback which performs a RollbackRetaining.
> 3) The qrCustomer.Scroll Events are NOT called. (Correct...)
>
> Obviously, something in the first Commit caused IBO to fire the
> Scroll events on a subsequent Rollback. To me, this is a bug.
>
> This problem may sound like a nit to other developers, but in my
> program, it causes real problems (as stated below).
>
> Eric.
>
> --- In IBObjects@y..., "Eric Handbury" <ehandbury@h...> wrote:
> > Hello,
> >
> > I have a Customer-BeforeScroll event which closes all datasets
> > opened during the displaying of the previous Customer. It could
> close
> > dozens of datasets depending on the Tabs that the user has
> displaying.
> >
> > My problem is as follows:
> > 1) User goes to a particular Customer Tab which opens a couple of
> > datasets.
> > 2) User edits some field which sets qrCustomer->State to dssEdit.
> > 3) Users says Ooops, and hits the Cancel button which generates a
> > RollbackRetaining.
> > 4) IBO generates the following call-stack:
> >
> > 004371B9 TFileDM::CloseCustQueries(this=:01524C98)
> > 00438B13 TFileDM::qrCustomerBeforeScroll(this=:01524C98,
> > IB_Dataset=:01743A24)
> > 005AEF59 Ib_components::LaunchDSEvent(DS=:01743A24, EV=
> > {TFileDM::qrCustomerBeforeScroll,:01524C98})
> > 005AF152 Ib_components::TIB_Dataset::DoBeforeScroll(Self=:01743A24)
> > 005AEA60 Ib_components::TIB_Dataset::SysBeforeScroll(Self=:01743A24)
> > 005B52F7 Ib_components::TIB_BDataset::SysBeforeScroll
> (Self=:01743A24)
> > 005A73CF Ib_components::TIB_Dataset::SysRefresh(Self=:01743A24,
> > Rows=true, Keys=true)
> > 005A6C6C Ib_components::TIB_Dataset::RefreshAll(Self=:01743A24)
> > 005A6C05 Ib_components::TIB_Dataset::Refresh(Self=:01743A24)
> > 00595C82 Ib_components::TIB_Transaction::API_RollbackRetaining
> > (Self=:01526200)
> > 00594482 Ib_components::TIB_Transaction::SysRollbackRetaining
> > (Self=:01526200)
> > 005930DB Ib_components::TIB_Transaction::RollbackRetaining
> > (Self=:01526200)
> > 00414C93 TFileForm::CancelBtnClick(this=:017730C8, Sender=:01C5EEC0)
> >
> > 5) My BeforeScroll event then closes all datasets thinking that
> the
> > Customer has changed, but in reality, the Customer has not changed
> > but only the State has changed (from dssEdit to dssBrowse).
> >
> > 6) Consequently, the user hits the Cancel button and all his
> > Customer data has disappeared. (due to my BeforeScroll event
> closing
> > all the datasets).
> >
> > Therefore, I would like IBO to NOT call the Scroll events if
> there
> > is a Rollback on a Edit. I can understand a Scroll on a Insert or
> > Delete where the rows in the Dataset have indeed changed... but not
> > on a Edit. IBO may have to re-fill the buffer with the correct data
> > for that row, but it hasn't Scrolled.
> >
> > Eric.