| Subject | [IBO] Re: More Scroll Questions... (More Info) |
|---|---|
| Author | Eric Handbury |
| Post date | 2002-10-16T21:31:17Z |
--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
1) Its what you say above... that the Rollback is doing an
unnecessary Refresh. This is what I tried to tell Geoff... that the
transaction events should be independent of each other. So if I do a
Commit followed by an Edit folowed by a Rollback, IBO should not be
concerned about happened before the last SavePoint. Nothing was
Posted before the Rollback so IBO must have the correct data in its
buffers.
But I really don't care about that... if IBO has to do one to
ensure it has the proper data then thats fine.
2) The real problem is: if the internal Refresh is done, then the
Scroll events are fired. This is wrong since only a Refresh has been
done, not a RowNum change. The Scroll Events should be confined to
user-initiated RowNum changes, (like Grid operations, or NavBar
operations, or cancelled Inserts, etc.), not IBO internal data
refreshes.
I am sending you a sample program which illustrates the problem.
been unable to do so. Subsequently, I have been forced to remove all
my code from the Scroll Events which tries to intelligently
open/close datasets depending on user actions. My sample application
shows how the datasets are suddenly closed in the middle of a user
session as a result of this problem. I will just have to leave all
datasets open for the duration of the user session, which I don't
want.
> Ok, I got this now, I hadn't seen this yet.I've tried
>
> When doing a rollback it is sometimes necessary to do a refresh.
> to make IBO intelligent about it, but there are just cases I cannotget away
> from. Perhaps what you are saying here, which could be possible, isthat I
> am doing an operation internally that isn't necessary since therewas
> nothing posted prior to the call to Rollback.There's really two parts then:
1) Its what you say above... that the Rollback is doing an
unnecessary Refresh. This is what I tried to tell Geoff... that the
transaction events should be independent of each other. So if I do a
Commit followed by an Edit folowed by a Rollback, IBO should not be
concerned about happened before the last SavePoint. Nothing was
Posted before the Rollback so IBO must have the correct data in its
buffers.
But I really don't care about that... if IBO has to do one to
ensure it has the proper data then thats fine.
2) The real problem is: if the internal Refresh is done, then the
Scroll events are fired. This is wrong since only a Refresh has been
done, not a RowNum change. The Scroll Events should be confined to
user-initiated RowNum changes, (like Grid operations, or NavBar
operations, or cancelled Inserts, etc.), not IBO internal data
refreshes.
I am sending you a sample program which illustrates the problem.
> I'll log this as an item to look into, but I advise you to makeyour program
> work around this as a matter of principle. Doing a Refresh inresponse to a
> Rollback just may be necessary in some cases.As discussed with Geoff, I would love to find a workaround but have
been unable to do so. Subsequently, I have been forced to remove all
my code from the Scroll Events which tries to intelligently
open/close datasets depending on user actions. My sample application
shows how the datasets are suddenly closed in the middle of a user
session as a result of this problem. I will just have to leave all
datasets open for the duration of the user session, which I don't
want.