Subject | Re: [IBO] Transaction and ComboBox |
---|---|
Author | Jason Wharton |
Post date | 2001-07-17T22:55:39Z |
Russell,
I presume you don't want the accept/reject button to be enabled until they
have actually posted a change to the server?
In this case you should examine the TransactionStatus which will actually
differentiate between active and active pending.
I don't quite follow how the TIB_ComboBox is different from the other
controls however. Once a change is made and a dataset goes into edit state
that should be all there is to it. Please clarify this for me.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
I presume you don't want the accept/reject button to be enabled until they
have actually posted a change to the server?
In this case you should examine the TransactionStatus which will actually
differentiate between active and active pending.
I don't quite follow how the TIB_ComboBox is different from the other
controls however. Once a change is made and a dataset goes into edit state
that should be all there is to it. Please clarify this for me.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "Russell Belding" <russell@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, July 17, 2001 3:10 PM
Subject: [IBO] Transaction and ComboBox
> Hello Team IBO
>
> I want to suggest that the criteria by which a TIB_ComboBox tells its
parent transaction to set TransactionState to tsActive should be changed.
Being new to Interbase and IBObjects I welcome correction to any
misunderstanding I have.
>
> The background to my comments is I have D5 forms using several
iboControls, all using a TIB_Query and one TIB_Transaction. The work unit my
app user does is accepted or rejected by them by pressing, naturally, an
accept or reject button. So I need to manage programatically when the
accept/reject buttons are enabled.
>
> Users may change several rows in one work unit, to allow for this I have a
TIB_NavigationBar on the form. The state property of the TIB_Query cannot be
used to enable/disable the accept/reject buttons because its state property
is reset to dssBrowse when the current row changes. So uncommited changes
are not detected by examining the TIB_Query state.
>
> I am using Accept/RejectButtons.enabled :=
Transaction.TransactionIsActive.
>
> This works correctly as far as I can tell, except for the TIB_ComboBox. If
a user pulls down the ComboBox list and selects the existing choice the
transaction state switches to tsActive, and I interpret this as the user has
made a change. From my users viewpoint they have not made a change, but I am
enabling the accept/reject buttons because I rely on the transaction state
for this.
>
> The change I suggest is the TIB_ComboBox behave like the TIB_LookupCombo
and not cause the transaction to go active when the existing selection is
reselected. (I can probably achieve what I want by adding code inside my app
but it may be better to change the TIB_ComboBox)
>
> This change makes sense to me in that it makes the TIB_ComboBox behaviour
consistent with other controls and it solves my problem. Perhaps there are
reasons not to make the change?
>
> Is there a better way to manage Accept/RejectButton.Enabled?
>
> (The IBO version I am using is 3.6Dg or h or i. The version code on the
components says g. With D5. )
>
> Thanks
>
> Russell
>