ttheimer
asked on
Programmatically changing the value of a DB-linked component (Delphi)
If I use code in the OnExit event handler of one control to change the value of another DB-linked control I see a range of unwanted behaviors such as the value not appearing in the second field until I click elsewhere on the form or the value appears in the field but disappears when the field is in focus.
I can code the event handler to change the database value directly but there are times that I don't want the change posted immediately.
So how do I modify the value of a db-linked control via code and have the field otherwise behave as it does when the value is typed in the field by the user?
I can code the event handler to change the database value directly but there are times that I don't want the change posted immediately.
So how do I modify the value of a db-linked control via code and have the field otherwise behave as it does when the value is typed in the field by the user?
Geert G
are we talking about devexpress controls ?
Yes you're going to have to give us more than that -
what components are we talking about here? What dataset are you using? And while we're at it, what database?
Some developers have expressed concern previously that when they try to change values by editing component values (rather than talking to the dataset directly) they get some undesirable results. As a best-practise it seems you should be talking to your dataset directly, as in
ADOTable1.Edit;
ADOTable1.Fieldbyname('MyF
ADOTable1.Post;
//and maybe ADOTable1.Edit again;
Not also that usually if you edit a data-aware control, it will place the dataset into Edit Mode automatically if the dataset will allow editing. However as a best-practise you should place the dataset into edit mode yourself in case of any complications, for example:
ADOTable1.Edit;
DBDateTimePicker.Date := Today;
And finally, it is of course possible to check whether or not a dataset is in edit or insert mode. This may or may not be relevant for your scenario:
uses db;
If (ADOTable1.state = dsEdit) or (ADOTable1.state = dsInsert) then
//if the dataset is in edit or insert mode
OR
uses db;
if ADOTable.state <> dsBrowse then; //if the dataset is not in Browse mode;
what components are we talking about here? What dataset are you using? And while we're at it, what database?
Some developers have expressed concern previously that when they try to change values by editing component values (rather than talking to the dataset directly) they get some undesirable results. As a best-practise it seems you should be talking to your dataset directly, as in
ADOTable1.Edit;
ADOTable1.Fieldbyname('MyF
ADOTable1.Post;
//and maybe ADOTable1.Edit again;
Not also that usually if you edit a data-aware control, it will place the dataset into Edit Mode automatically if the dataset will allow editing. However as a best-practise you should place the dataset into edit mode yourself in case of any complications, for example:
ADOTable1.Edit;
DBDateTimePicker.Date := Today;
And finally, it is of course possible to check whether or not a dataset is in edit or insert mode. This may or may not be relevant for your scenario:
uses db;
If (ADOTable1.state = dsEdit) or (ADOTable1.state = dsInsert) then
//if the dataset is in edit or insert mode
OR
uses db;
if ADOTable.state <> dsBrowse then; //if the dataset is not in Browse mode;
ASKER
Geert,
I don't see any clues that I am working with DevEx components but that is spot on. I thought I saw similar behavior when I did a quick mock up using similar Delphi core controls. Is there a recommended practice for DevEx data aware controls that is different from other controls?
Tom
I don't see any clues that I am working with DevEx components but that is spot on. I thought I saw similar behavior when I did a quick mock up using similar Delphi core controls. Is there a recommended practice for DevEx data aware controls that is different from other controls?
Tom
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Geert,
A solution that seems to be working, though cumbersome, is to set a flag when the user enters the control and unset the flag when the user leaves. The onchange or oneditvaluechange can then check this flag. If the change was the result of the data value being loaded from the database then the flag will be unset and my event handler will exit without running the code that is specifically for user-initiated actions.
Thanks.
Tom
A solution that seems to be working, though cumbersome, is to set a flag when the user enters the control and unset the flag when the user leaves. The onchange or oneditvaluechange can then check this flag. If the change was the result of the data value being loaded from the database then the flag will be unset and my event handler will exit without running the code that is specifically for user-initiated actions.
Thanks.
Tom