Subject | Re: [IBO] Transaction events... |
---|---|
Author | Helen Borrie |
Post date | 2005-08-11T10:33:11Z |
At 09:38 AM 11/08/2005 +0000, you wrote:
transaction state, so what could one deduce from that?
Could you just set up a property - of type TIB_TransactionState - into
which you can store the value of the TransactionState in the the
BeforeCommit and BeforeRollback events? In the AfterEnd event, check
whether this saved value is greater than zero (=tsNone) then reset it to
zero once you have the info you want. This value will tell you exactly what
your Sound Choosing routine needs to know.
Helen
>Hi!Errrm, I don't think so! The passage of time is not going to change the
>
>My blind customers demand that sounds be heard on "Save" and "Undo".
>Some users are advanced enough to make a differende between
>Post/Cancel and Commit/Rollback. Some are not and they continually
>Commit in stead of Posting a couple of times before Comitting.
>
>Playing sound on Post/Cancel events of the dataset seems to be no
>problem. Also Rollback/RollbackRetaining events are fired only when
>that really happens.
>
>But for Commit/CommitRetaining...
>
>I tried to put an event function into AfterCommit and
>AfterCommitRetaining but at that stage the transaction is already
>tsInactive. Problem is that I can not differ between a
>Commit/CommitRetaining done after the transaction really was active
>and one done when the transaction was inactive (happens a lot on
>scrolls and such).
>
>It's simple when one is doing toolbar buttons, they don't mind a
>couple of extra calls as long as the status is not changed. Playing
>sounds though I really need to know if a Commit/CommitRetaining was
>_physically_ done. Did the transaction have anything pending, that is.
>
>I tried to look at the transactions status in
>BeforeCommit/BeforeCommitRetaining but that is the same. Always the
>same status when these functions are executed.
>
>I also tried to put a TIB_TransactionSource on the form and hook into
>StatusChanged but since it's a product of the events mentioned above
>it's a no go.
>
>Anybody has aby ideas? Going the other way around (hooking into the
>GUI/VCL) is no good because Commit/CommitRetaining can happen from
>lots of different places and I don't think it would solve the problem.
>
>Perhaps a timer firing some every 0,1 second and comparing transaction
>states? Is that advisable?
transaction state, so what could one deduce from that?
Could you just set up a property - of type TIB_TransactionState - into
which you can store the value of the TransactionState in the the
BeforeCommit and BeforeRollback events? In the AfterEnd event, check
whether this saved value is greater than zero (=tsNone) then reset it to
zero once you have the info you want. This value will tell you exactly what
your Sound Choosing routine needs to know.
Helen