--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> At 09:38 AM 11/08/2005 +0000, you wrote:
> >Hi!
> >
> >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?
>
> Errrm, I don't think so! The passage of time is not going to change the
> 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

Actually I posted a bit too fast. The TransactionSource StatusChanged
event is perfect because it *does* fire when state changes from
tsActivePending or tsActive to something else and *that* is exactly
what I need :) At least it seems so at the moment ;)

The foresight of this man Jason is often astounding.

Thanks!

/Dany