Preventing change of key fields in CRecordView?
-
Hi! I have this software package I am maintaining and I have run into a small glitch because of the way CRecordView handles moves. Imagine an entry window where you enter and update people. The key is an integer. If you enter a number in the key field the corresponding person is displayed. Now assume that you have a person on-screen and then change the number, but instead of leaving the field (which would trigger a lookup) you hit "PreviousRecord". This triggers an OnMove and that will do a save before the move and presto! You have changed the number of that person which was probably not what you intended. The workaround which I have dreamed up on sleepless nights is to add a boolean to the class that all fields inherit from and check that in DoDataExchange, ie the field is normally FALSE, but TRUE for key fields. In the DDX function I check if(pField->m_bKeyField && pDX->m_bSaveAndValidate) and only allow the DDX if m_bAddMode is true. For non-key fields I just do the DDX. This will prevent updating the key field unless we are adding a new record. How does this sound? Totally bad? Is there a better way?
How about just overriding
CRecordView::OnMove()(it's virtual) and do everything that the base method does except for updating.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
-
How about just overriding
CRecordView::OnMove()(it's virtual) and do everything that the base method does except for updating.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
Yes, but the problem is that I do not want to block updates completely. Say that someone is moving through the records on-screen and updating them. In that case they will lose the update if they change a field and move to the next. It is just the key/id field that I want to protect on existing records. Am I making sense? ;)
-
Hi! I have this software package I am maintaining and I have run into a small glitch because of the way CRecordView handles moves. Imagine an entry window where you enter and update people. The key is an integer. If you enter a number in the key field the corresponding person is displayed. Now assume that you have a person on-screen and then change the number, but instead of leaving the field (which would trigger a lookup) you hit "PreviousRecord". This triggers an OnMove and that will do a save before the move and presto! You have changed the number of that person which was probably not what you intended. The workaround which I have dreamed up on sleepless nights is to add a boolean to the class that all fields inherit from and check that in DoDataExchange, ie the field is normally FALSE, but TRUE for key fields. In the DDX function I check if(pField->m_bKeyField && pDX->m_bSaveAndValidate) and only allow the DDX if m_bAddMode is true. For non-key fields I just do the DDX. This will prevent updating the key field unless we are adding a new record. How does this sound? Totally bad? Is there a better way?
Remember the previous value in the key field and restore it in the PreviousRecord handler before doing the OnMove.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
-
Remember the previous value in the key field and restore it in the PreviousRecord handler before doing the OnMove.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
"PreviousRecord handler" Now you lost me? Where is that? Ie member of what class?
-
Yes, but the problem is that I do not want to block updates completely. Say that someone is moving through the records on-screen and updating them. In that case they will lose the update if they change a field and move to the next. It is just the key/id field that I want to protect on existing records. Am I making sense? ;)
Is it imperitive that this "key field" be manually assigned/updated? If not, just change the field in the database to be auto-increment. Remove that one field from the recordset class. When a new record is added, it will get the next available number. When the navigational buttons are clicked, no update to the auto-increment will take place. Another option would be to add a "Go To" button next to the edit box containing the key field. That way, this button would not be tied to the other navigational buttons.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
-
Is it imperitive that this "key field" be manually assigned/updated? If not, just change the field in the database to be auto-increment. Remove that one field from the recordset class. When a new record is added, it will get the next available number. When the navigational buttons are clicked, no update to the auto-increment will take place. Another option would be to add a "Go To" button next to the edit box containing the key field. That way, this button would not be tied to the other navigational buttons.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
"Is it imperitive that this "key field" be manually assigned/updated? " Yes, unfortunately. The user must be able to specify new items. An analogy would be a POS system where the unique ID is the EAN-code. "Another option would be to add a "Go To" button next to the edit box containing the key field. That way, this button would not be tied to the other navigational buttons." Not sure that I follow you there?
-
"PreviousRecord handler" Now you lost me? Where is that? Ie member of what class?
I mean whichever function gets called when the user presses "PreviousRecord"
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
-
I mean whichever function gets called when the user presses "PreviousRecord"
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
OK. That means OnMove. But that would mean a rather complicated copy of OnMove in every data input view and there are at least ten of them for various tables. If I prevent the DDX in the class (derived from RecordView where they all inherit, then I need just one line per data input view, to set one or more fields as "protected" unless we are adding a new record.
-
"Is it imperitive that this "key field" be manually assigned/updated? " Yes, unfortunately. The user must be able to specify new items. An analogy would be a POS system where the unique ID is the EAN-code. "Another option would be to add a "Go To" button next to the edit box containing the key field. That way, this button would not be tied to the other navigational buttons." Not sure that I follow you there?
Anders Gustafsson wrote:
Not sure that I follow you there?
I meant to say there should be two additional buttons. One labeled "Go To" and the other labeled "Add." Now if you type in an item number and click the "Add" button, it will clear the form and add a new record with that item number. If you type in an item number and click the "Go To" button, it will populate the form with that item's information. If you click one of the navigational buttons, appropriate item will be displayed.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
-
Anders Gustafsson wrote:
Not sure that I follow you there?
I meant to say there should be two additional buttons. One labeled "Go To" and the other labeled "Add." Now if you type in an item number and click the "Add" button, it will clear the form and add a new record with that item number. If you type in an item number and click the "Go To" button, it will populate the form with that item's information. If you click one of the navigational buttons, appropriate item will be displayed.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
OK. Problem is that I cannot rely on buttons alone. The app must be navigable by keyboard alone. Skilled operators get very nervous when they have to take their hands off the keyboard. At the same time the system should be friendly to novices :) One very drastic solution would be to disable the nav-buttons entirely, but that would make me rather unpopular with existing users. Any thoughts about my idea to "mark" fields and prevent the DDX unless we are in add mode?
-
OK. Problem is that I cannot rely on buttons alone. The app must be navigable by keyboard alone. Skilled operators get very nervous when they have to take their hands off the keyboard. At the same time the system should be friendly to novices :) One very drastic solution would be to disable the nav-buttons entirely, but that would make me rather unpopular with existing users. Any thoughts about my idea to "mark" fields and prevent the DDX unless we are in add mode?
Anders Gustafsson wrote:
Any thoughts about my idea to "mark" fields and prevent the DDX unless we are in add mode?
Sounds good.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
-
Anders Gustafsson wrote:
Any thoughts about my idea to "mark" fields and prevent the DDX unless we are in add mode?
Sounds good.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
OK. Thanks. I will try that approach and have some users betatest it.