Subject Re: More Scroll Questions... (More Info)
Author Eric Handbury
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.