If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Prevent edits - unexpected effects
The form's Current event runs when you arrive at a record. No editing has
begun at this stage, so there is no danger, (unless you are also assigning a value to a bound control in Form_Current.) When you click the button to lock the form, it attempts to save the record before doing anything else. (Notice how 'Save any edits' comes first.) If the safe fails, the code drops to the error handler, and so the locking/unlocking status does not change. If you place the code in Form_AfterUpdate, again you are guaranteed that the form is not dirty at this stage (unless your code dirties it), so again there is no chance of failure. Or did you misunderstand and use the AfterUpdate of the control instead of the form? -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message news This has been working quite well until now when I noticed that if the user were to click the 'Complete' checkbox on a new record w/o first having entered the required ID data (there's also an MRADATE field which is set to 'required') that a error message '3314 - The field 'tbl_MRA_Form.ID' cannot contain a Null value because the Required property for this field is set to True. Enter a value in this field" shows up! Ordinarily the person entering these data oughtn't be attempting to lock an empty record so it's not likely to be ongoing; on the other hand, I noticed that the check in the 'Complete' checkbox is present after the user hits the 'Ok' on error 3314's msg? That means that the form is coded as having been locked and completed even before any valid data is entered. Any thoughts? "Allen Browne" wrote: We assume you already have the code from this article in your database: http://allenbrowne.com/ser-56.html Steps: 1. Open the form in design view. 2. In the Properties box, looking at the properties of the Form, on the Event tab, set the On Current property to: [Event Procedure] 3. Click the Build button (...) beside this property. Acdess opens the code window. 4. Set up the code like this: Private Sub Form_Current() Call LockBoundControls(Nz(Me.Complete.Value, False)) End Sub -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message ... I think this is really going to be helpful.... I hate to bother you, but I think this posting could use a little more detail: How do you mean 'call the code in form_current and form_afterupdate', passing NZ(Me.Complete.value,False)'? I already have some code in the on current event of the form's but not in the after update one. I guess this scenario of mine does not involve creating the button in your download instructions but that a red rectangle is a good idea. Basically, I need to be able to wrap my mind around the mechanics of implementing your workaround/suggestion. TIA "Allen Browne" wrote: Call the code in Form_Current, and Form_AfterUpdate, passing: Nz(Me.Completed.Value, False) If the check box is true, this will lock it. If the check box is false, this will unlock the record. If the check box is null (e.g. at a new record), it will unlock it. "Access User" wrote in message ... I've had a chance to implement this code and controls onto my form and I think I understand what it's doing and what it isn't doing. It seems to lock the user out from making any modifications to any records bound to the form/subform. What would like is to allow the user to see which records have been entered completely into the database. I currently have a checkbox control on it which is bound to a field in the underlying table and is called 'Complete'. Its label is red if it's been checked and green if it hasn't been and its status varies from one record to the next as the user scrolls through each record. But it fails to do what your cmdbutton did and that is prevent any edits to a record once the checkbox is selected. Thoughts? "Allen Browne" wrote: Setting AllowEdits to No for a form affects all controls on the form. Therefore the subform control is locked well. Even unbound controls are unusable. Here's an alternative approach: Locking bound controls on a form and subforms at: http://allenbrowne.com/ser-56.html This is a piece of code that leaves the form's AllowEdits property unchanged, but sets the Locked property of the bound controls instead. The unbound controls are therefore still usable. The code does lock the subforms too, but it accepts a list of controls to NOT lock. So, if you tell it not to lock your subform, it leaves it unchanged. "chris" wrote in message ... I have a form which I have locked for edits (in properties) to avoid accidental changes to data, and have place a command button on it to allow edits. There is a subform on this form which previously allowed users to add new associated records through the normal add record row at the bottom. However, when I chose to prevent edits on the main form I found that the add records row in the subform was greyed out. Clicking the command button to allow edits to the main form did not affect the subform. Has anyone got any idea why is might be happening and how I can overcome the problem? |
#12
|
|||
|
|||
Prevent edits - unexpected effects
You're right, it was in 'Complete' control's After_Update, so I removed and
placed it in the parent's AU event property. But, here's the rub....it switches the status of the 'Complete' checkbox's to 'Yes' (check is entered) and, even after having entered the missing requisite data the form is actually not locked! "Allen Browne" wrote: The form's Current event runs when you arrive at a record. No editing has begun at this stage, so there is no danger, (unless you are also assigning a value to a bound control in Form_Current.) When you click the button to lock the form, it attempts to save the record before doing anything else. (Notice how 'Save any edits' comes first.) If the safe fails, the code drops to the error handler, and so the locking/unlocking status does not change. If you place the code in Form_AfterUpdate, again you are guaranteed that the form is not dirty at this stage (unless your code dirties it), so again there is no chance of failure. Or did you misunderstand and use the AfterUpdate of the control instead of the form? -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message news This has been working quite well until now when I noticed that if the user were to click the 'Complete' checkbox on a new record w/o first having entered the required ID data (there's also an MRADATE field which is set to 'required') that a error message '3314 - The field 'tbl_MRA_Form.ID' cannot contain a Null value because the Required property for this field is set to True. Enter a value in this field" shows up! Ordinarily the person entering these data oughtn't be attempting to lock an empty record so it's not likely to be ongoing; on the other hand, I noticed that the check in the 'Complete' checkbox is present after the user hits the 'Ok' on error 3314's msg? That means that the form is coded as having been locked and completed even before any valid data is entered. Any thoughts? "Allen Browne" wrote: We assume you already have the code from this article in your database: http://allenbrowne.com/ser-56.html Steps: 1. Open the form in design view. 2. In the Properties box, looking at the properties of the Form, on the Event tab, set the On Current property to: [Event Procedure] 3. Click the Build button (...) beside this property. Acdess opens the code window. 4. Set up the code like this: Private Sub Form_Current() Call LockBoundControls(Nz(Me.Complete.Value, False)) End Sub -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message ... I think this is really going to be helpful.... I hate to bother you, but I think this posting could use a little more detail: How do you mean 'call the code in form_current and form_afterupdate', passing NZ(Me.Complete.value,False)'? I already have some code in the on current event of the form's but not in the after update one. I guess this scenario of mine does not involve creating the button in your download instructions but that a red rectangle is a good idea. Basically, I need to be able to wrap my mind around the mechanics of implementing your workaround/suggestion. TIA "Allen Browne" wrote: Call the code in Form_Current, and Form_AfterUpdate, passing: Nz(Me.Completed.Value, False) If the check box is true, this will lock it. If the check box is false, this will unlock the record. If the check box is null (e.g. at a new record), it will unlock it. "Access User" wrote in message ... I've had a chance to implement this code and controls onto my form and I think I understand what it's doing and what it isn't doing. It seems to lock the user out from making any modifications to any records bound to the form/subform. What would like is to allow the user to see which records have been entered completely into the database. I currently have a checkbox control on it which is bound to a field in the underlying table and is called 'Complete'. Its label is red if it's been checked and green if it hasn't been and its status varies from one record to the next as the user scrolls through each record. But it fails to do what your cmdbutton did and that is prevent any edits to a record once the checkbox is selected. Thoughts? "Allen Browne" wrote: Setting AllowEdits to No for a form affects all controls on the form. Therefore the subform control is locked well. Even unbound controls are unusable. Here's an alternative approach: Locking bound controls on a form and subforms at: http://allenbrowne.com/ser-56.html This is a piece of code that leaves the form's AllowEdits property unchanged, but sets the Locked property of the bound controls instead. The unbound controls are therefore still usable. The code does lock the subforms too, but it accepts a list of controls to NOT lock. So, if you tell it not to lock your subform, it leaves it unchanged. "chris" wrote in message ... I have a form which I have locked for edits (in properties) to avoid accidental changes to data, and have place a command button on it to allow edits. There is a subform on this form which previously allowed users to add new associated records through the normal add record row at the bottom. However, when I chose to prevent edits on the main form I found that the add records row in the subform was greyed out. Clicking the command button to allow edits to the main form did not affect the subform. Has anyone got any idea why is might be happening and how I can overcome the problem? |
#13
|
|||
|
|||
Prevent edits - unexpected effects
"Access User" wrote in message
... ... it switches the status of the 'Complete' checkbox's to 'Yes' (check is entered) and, even after having entered the missing requisite data the form is actually not locked! This indicates you are programmatically dirtying the form. You can verify this by turning on the form's RecordSelector property. The record selector (bar at the left of the record) then changes icon from an arrow to a pencil when the form is dirtied. -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. |
#14
|
|||
|
|||
Prevent edits - unexpected effects
After moving the call code to the form AU from the Complete ctrl's AU event
property, I now find that when you're on the record and check the box of the Complete ctrl's to lock it, that the record is still editable until you scroll to another record and return to it, at which point it is actually locked? This was not so when the call code was on the Complete ctrl's AU event property - in that scenario, once the control was checked the record was locked while sitting on it? "Allen Browne" wrote: The form's Current event runs when you arrive at a record. No editing has begun at this stage, so there is no danger, (unless you are also assigning a value to a bound control in Form_Current.) When you click the button to lock the form, it attempts to save the record before doing anything else. (Notice how 'Save any edits' comes first.) If the safe fails, the code drops to the error handler, and so the locking/unlocking status does not change. If you place the code in Form_AfterUpdate, again you are guaranteed that the form is not dirty at this stage (unless your code dirties it), so again there is no chance of failure. Or did you misunderstand and use the AfterUpdate of the control instead of the form? -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message news This has been working quite well until now when I noticed that if the user were to click the 'Complete' checkbox on a new record w/o first having entered the required ID data (there's also an MRADATE field which is set to 'required') that a error message '3314 - The field 'tbl_MRA_Form.ID' cannot contain a Null value because the Required property for this field is set to True. Enter a value in this field" shows up! Ordinarily the person entering these data oughtn't be attempting to lock an empty record so it's not likely to be ongoing; on the other hand, I noticed that the check in the 'Complete' checkbox is present after the user hits the 'Ok' on error 3314's msg? That means that the form is coded as having been locked and completed even before any valid data is entered. Any thoughts? "Allen Browne" wrote: We assume you already have the code from this article in your database: http://allenbrowne.com/ser-56.html Steps: 1. Open the form in design view. 2. In the Properties box, looking at the properties of the Form, on the Event tab, set the On Current property to: [Event Procedure] 3. Click the Build button (...) beside this property. Acdess opens the code window. 4. Set up the code like this: Private Sub Form_Current() Call LockBoundControls(Nz(Me.Complete.Value, False)) End Sub -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message ... I think this is really going to be helpful.... I hate to bother you, but I think this posting could use a little more detail: How do you mean 'call the code in form_current and form_afterupdate', passing NZ(Me.Complete.value,False)'? I already have some code in the on current event of the form's but not in the after update one. I guess this scenario of mine does not involve creating the button in your download instructions but that a red rectangle is a good idea. Basically, I need to be able to wrap my mind around the mechanics of implementing your workaround/suggestion. TIA "Allen Browne" wrote: Call the code in Form_Current, and Form_AfterUpdate, passing: Nz(Me.Completed.Value, False) If the check box is true, this will lock it. If the check box is false, this will unlock the record. If the check box is null (e.g. at a new record), it will unlock it. "Access User" wrote in message ... I've had a chance to implement this code and controls onto my form and I think I understand what it's doing and what it isn't doing. It seems to lock the user out from making any modifications to any records bound to the form/subform. What would like is to allow the user to see which records have been entered completely into the database. I currently have a checkbox control on it which is bound to a field in the underlying table and is called 'Complete'. Its label is red if it's been checked and green if it hasn't been and its status varies from one record to the next as the user scrolls through each record. But it fails to do what your cmdbutton did and that is prevent any edits to a record once the checkbox is selected. Thoughts? "Allen Browne" wrote: Setting AllowEdits to No for a form affects all controls on the form. Therefore the subform control is locked well. Even unbound controls are unusable. Here's an alternative approach: Locking bound controls on a form and subforms at: http://allenbrowne.com/ser-56.html This is a piece of code that leaves the form's AllowEdits property unchanged, but sets the Locked property of the bound controls instead. The unbound controls are therefore still usable. The code does lock the subforms too, but it accepts a list of controls to NOT lock. So, if you tell it not to lock your subform, it leaves it unchanged. "chris" wrote in message ... I have a form which I have locked for edits (in properties) to avoid accidental changes to data, and have place a command button on it to allow edits. There is a subform on this form which previously allowed users to add new associated records through the normal add record row at the bottom. However, when I chose to prevent edits on the main form I found that the add records row in the subform was greyed out. Clicking the command button to allow edits to the main form did not affect the subform. Has anyone got any idea why is might be happening and how I can overcome the problem? |
#15
|
|||
|
|||
Prevent edits - unexpected effects
Can I have something like this
Private Sub Complete_AfterUpdate() Call LockBoundControls([Form], Nz(Me.Complete.Value, False), "Complete") If Me.Complete = -1 Then Me![Label59].BackColor = vbGreen Me![Label59].ForeColor = vbBlack Me![Label59].Caption = "Form is: LOCKED" End If If Me.Complete = 0 Then Me![Label59].BackColor = vbRed Me![Label59].ForeColor = vbYellow Me![Label59].Caption = "Form is: UNLOCKED" End If End Sub Private Sub Form_AfterUpdate() Call LockBoundControls([Form], Nz(Me.Complete.Value, False), "Complete") End Sub Private Sub Form_Current() Call LockBoundControls([Form], Nz(Me.Complete.Value, False), "Complete") If (Me.NUMBPOSS Me.NUMBDEF) Then Me![Label53].BackColor = vbRed Me![Label53].ForeColor = vbYellow Me![Label53].Caption = "Correction Requested: DEFINITES" Me![Label55].ForeColor = vbYellow Me![Label55].BackColor = vbRed Me![Label55].Caption = "Correction Requested: POSSIBLES" End If If Not (Me.NUMBPOSS Me.NUMBDEF) Then Me![Label53].BackColor = vbWhite Me![Label53].ForeColor = vbBlack Me.[Label53].Caption = "How Many DEFINITE Aneurisms Seen?" Me![Label55].BackColor = vbWhite Me![Label55].ForeColor = vbBlack Me.[Label55].Caption = "How Many POSSIBLE Aneurisms Seen?" End If .....more such code like this End Sub I like the fact that when your call routing is on the control Complete, the user is instantly prevented from further edits/deletes. "Allen Browne" wrote: "Access User" wrote in message ... ... it switches the status of the 'Complete' checkbox's to 'Yes' (check is entered) and, even after having entered the missing requisite data the form is actually not locked! This indicates you are programmatically dirtying the form. You can verify this by turning on the form's RecordSelector property. The record selector (bar at the left of the record) then changes icon from an arrow to a pencil when the form is dirtied. -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. |
#16
|
|||
|
|||
Prevent edits - unexpected effects
Omit the LockBoundControls() call from the after update even of the control.
Don't lock it until the record is saved. Otherwise you are toggling it unnecessarily, and too many times. -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message ... Can I have something like this Private Sub Complete_AfterUpdate() Call LockBoundControls([Form], Nz(Me.Complete.Value, False), "Complete") If Me.Complete = -1 Then Me![Label59].BackColor = vbGreen Me![Label59].ForeColor = vbBlack Me![Label59].Caption = "Form is: LOCKED" End If If Me.Complete = 0 Then Me![Label59].BackColor = vbRed Me![Label59].ForeColor = vbYellow Me![Label59].Caption = "Form is: UNLOCKED" End If End Sub Private Sub Form_AfterUpdate() Call LockBoundControls([Form], Nz(Me.Complete.Value, False), "Complete") End Sub Private Sub Form_Current() Call LockBoundControls([Form], Nz(Me.Complete.Value, False), "Complete") If (Me.NUMBPOSS Me.NUMBDEF) Then Me![Label53].BackColor = vbRed Me![Label53].ForeColor = vbYellow Me![Label53].Caption = "Correction Requested: DEFINITES" Me![Label55].ForeColor = vbYellow Me![Label55].BackColor = vbRed Me![Label55].Caption = "Correction Requested: POSSIBLES" End If If Not (Me.NUMBPOSS Me.NUMBDEF) Then Me![Label53].BackColor = vbWhite Me![Label53].ForeColor = vbBlack Me.[Label53].Caption = "How Many DEFINITE Aneurisms Seen?" Me![Label55].BackColor = vbWhite Me![Label55].ForeColor = vbBlack Me.[Label55].Caption = "How Many POSSIBLE Aneurisms Seen?" End If .....more such code like this End Sub I like the fact that when your call routing is on the control Complete, the user is instantly prevented from further edits/deletes. "Allen Browne" wrote: "Access User" wrote in message ... ... it switches the status of the 'Complete' checkbox's to 'Yes' (check is entered) and, even after having entered the missing requisite data the form is actually not locked! This indicates you are programmatically dirtying the form. You can verify this by turning on the form's RecordSelector property. The record selector (bar at the left of the record) then changes icon from an arrow to a pencil when the form is dirtied. -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. |
#17
|
|||
|
|||
Prevent edits - unexpected effects
I was trying to programmatically prevent the same from happening, but given
what I guess are heroic programming req'ts, I will stipulate this to the user. "Allen Browne" wrote: Omit the LockBoundControls() call from the after update even of the control. Don't lock it until the record is saved. Otherwise you are toggling it unnecessarily, and too many times. -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message ... Can I have something like this Private Sub Complete_AfterUpdate() Call LockBoundControls([Form], Nz(Me.Complete.Value, False), "Complete") If Me.Complete = -1 Then Me![Label59].BackColor = vbGreen Me![Label59].ForeColor = vbBlack Me![Label59].Caption = "Form is: LOCKED" End If If Me.Complete = 0 Then Me![Label59].BackColor = vbRed Me![Label59].ForeColor = vbYellow Me![Label59].Caption = "Form is: UNLOCKED" End If End Sub Private Sub Form_AfterUpdate() Call LockBoundControls([Form], Nz(Me.Complete.Value, False), "Complete") End Sub Private Sub Form_Current() Call LockBoundControls([Form], Nz(Me.Complete.Value, False), "Complete") If (Me.NUMBPOSS Me.NUMBDEF) Then Me![Label53].BackColor = vbRed Me![Label53].ForeColor = vbYellow Me![Label53].Caption = "Correction Requested: DEFINITES" Me![Label55].ForeColor = vbYellow Me![Label55].BackColor = vbRed Me![Label55].Caption = "Correction Requested: POSSIBLES" End If If Not (Me.NUMBPOSS Me.NUMBDEF) Then Me![Label53].BackColor = vbWhite Me![Label53].ForeColor = vbBlack Me.[Label53].Caption = "How Many DEFINITE Aneurisms Seen?" Me![Label55].BackColor = vbWhite Me![Label55].ForeColor = vbBlack Me.[Label55].Caption = "How Many POSSIBLE Aneurisms Seen?" End If .....more such code like this End Sub I like the fact that when your call routing is on the control Complete, the user is instantly prevented from further edits/deletes. "Allen Browne" wrote: "Access User" wrote in message ... ... it switches the status of the 'Complete' checkbox's to 'Yes' (check is entered) and, even after having entered the missing requisite data the form is actually not locked! This indicates you are programmatically dirtying the form. You can verify this by turning on the form's RecordSelector property. The record selector (bar at the left of the record) then changes icon from an arrow to a pencil when the form is dirtied. -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. |
#18
|
|||
|
|||
Prevent edits - unexpected effects
I have created a 'parent' form into which I am placing the form where all
this was going on before and I believe I ought to be putting the calls into the same events you cited in your response (below) into the 'parent' and removing them from the sub-form. Am I correct? Here are the calls as written Private Sub Form_AfterUpdate() Call LockBoundControls([Form], Nz(Me![tbl_MRA_Form].Form!Complete.Value, False), "Complete") End Sub Private Sub Form_Current() Call LockBoundControls([Form], Nz(Me![tbl_MRA_Form].Form!Complete.Value, False), "Complete") End Sub ....but....I can't seem to unlock the form when I click on the 'Complete' cmdbutton? "Allen Browne" wrote: Call the code in Form_Current, and Form_AfterUpdate, passing: Nz(Me.Completed.Value, False) If the check box is true, this will lock it. If the check box is false, this will unlock the record. If the check box is null (e.g. at a new record), it will unlock it. -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message ... I've had a chance to implement this code and controls onto my form and I think I understand what it's doing and what it isn't doing. It seems to lock the user out from making any modifications to any records bound to the form/subform. What would like is to allow the user to see which records have been entered completely into the database. I currently have a checkbox control on it which is bound to a field in the underlying table and is called 'Complete'. Its label is red if it's been checked and green if it hasn't been and its status varies from one record to the next as the user scrolls through each record. But it fails to do what your cmdbutton did and that is prevent any edits to a record once the checkbox is selected. Thoughts? "Allen Browne" wrote: Setting AllowEdits to No for a form affects all controls on the form. Therefore the subform control is locked well. Even unbound controls are unusable. Here's an alternative approach: Locking bound controls on a form and subforms at: http://allenbrowne.com/ser-56.html This is a piece of code that leaves the form's AllowEdits property unchanged, but sets the Locked property of the bound controls instead. The unbound controls are therefore still usable. The code does lock the subforms too, but it accepts a list of controls to NOT lock. So, if you tell it not to lock your subform, it leaves it unchanged. "chris" wrote in message ... I have a form which I have locked for edits (in properties) to avoid accidental changes to data, and have place a command button on it to allow edits. There is a subform on this form which previously allowed users to add new associated records through the normal add record row at the bottom. However, when I chose to prevent edits on the main form I found that the add records row in the subform was greyed out. Clicking the command button to allow edits to the main form did not affect the subform. Has anyone got any idea why is might be happening and how I can overcome the problem? Chris |
#19
|
|||
|
|||
Prevent edits - unexpected effects
You place the code into the events of the form you want to lock.
In code, use Me rather than [Form] I won't be able to follow up on this over the next week or two. Hopefully you will be able to take it from there. -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message ... I have created a 'parent' form into which I am placing the form where all this was going on before and I believe I ought to be putting the calls into the same events you cited in your response (below) into the 'parent' and removing them from the sub-form. Am I correct? Here are the calls as written Private Sub Form_AfterUpdate() Call LockBoundControls([Form], Nz(Me![tbl_MRA_Form].Form!Complete.Value, False), "Complete") End Sub Private Sub Form_Current() Call LockBoundControls([Form], Nz(Me![tbl_MRA_Form].Form!Complete.Value, False), "Complete") End Sub ...but....I can't seem to unlock the form when I click on the 'Complete' cmdbutton? "Allen Browne" wrote: Call the code in Form_Current, and Form_AfterUpdate, passing: Nz(Me.Completed.Value, False) If the check box is true, this will lock it. If the check box is false, this will unlock the record. If the check box is null (e.g. at a new record), it will unlock it. "Access User" wrote in message ... I've had a chance to implement this code and controls onto my form and I think I understand what it's doing and what it isn't doing. It seems to lock the user out from making any modifications to any records bound to the form/subform. What would like is to allow the user to see which records have been entered completely into the database. I currently have a checkbox control on it which is bound to a field in the underlying table and is called 'Complete'. Its label is red if it's been checked and green if it hasn't been and its status varies from one record to the next as the user scrolls through each record. But it fails to do what your cmdbutton did and that is prevent any edits to a record once the checkbox is selected. Thoughts? "Allen Browne" wrote: Setting AllowEdits to No for a form affects all controls on the form. Therefore the subform control is locked well. Even unbound controls are unusable. Here's an alternative approach: Locking bound controls on a form and subforms at: http://allenbrowne.com/ser-56.html This is a piece of code that leaves the form's AllowEdits property unchanged, but sets the Locked property of the bound controls instead. The unbound controls are therefore still usable. The code does lock the subforms too, but it accepts a list of controls to NOT lock. So, if you tell it not to lock your subform, it leaves it unchanged. "chris" wrote in message ... I have a form which I have locked for edits (in properties) to avoid accidental changes to data, and have place a command button on it to allow edits. There is a subform on this form which previously allowed users to add new associated records through the normal add record row at the bottom. However, when I chose to prevent edits on the main form I found that the add records row in the subform was greyed out. Clicking the command button to allow edits to the main form did not affect the subform. Has anyone got any idea why is might be happening and how I can overcome the problem? |
#20
|
|||
|
|||
Prevent edits - unexpected effects
Thanks, that's going to be a great help....how do you address the
location/names of the control(s) in a sub-form of the 'parent' form which you want to exempt from locking? "Allen Browne" wrote: You place the code into the events of the form you want to lock. In code, use Me rather than [Form] I won't be able to follow up on this over the next week or two. Hopefully you will be able to take it from there. -- Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org. "Access User" wrote in message ... I have created a 'parent' form into which I am placing the form where all this was going on before and I believe I ought to be putting the calls into the same events you cited in your response (below) into the 'parent' and removing them from the sub-form. Am I correct? Here are the calls as written Private Sub Form_AfterUpdate() Call LockBoundControls([Form], Nz(Me![tbl_MRA_Form].Form!Complete.Value, False), "Complete") End Sub Private Sub Form_Current() Call LockBoundControls([Form], Nz(Me![tbl_MRA_Form].Form!Complete.Value, False), "Complete") End Sub ...but....I can't seem to unlock the form when I click on the 'Complete' cmdbutton? "Allen Browne" wrote: Call the code in Form_Current, and Form_AfterUpdate, passing: Nz(Me.Completed.Value, False) If the check box is true, this will lock it. If the check box is false, this will unlock the record. If the check box is null (e.g. at a new record), it will unlock it. "Access User" wrote in message ... I've had a chance to implement this code and controls onto my form and I think I understand what it's doing and what it isn't doing. It seems to lock the user out from making any modifications to any records bound to the form/subform. What would like is to allow the user to see which records have been entered completely into the database. I currently have a checkbox control on it which is bound to a field in the underlying table and is called 'Complete'. Its label is red if it's been checked and green if it hasn't been and its status varies from one record to the next as the user scrolls through each record. But it fails to do what your cmdbutton did and that is prevent any edits to a record once the checkbox is selected. Thoughts? "Allen Browne" wrote: Setting AllowEdits to No for a form affects all controls on the form. Therefore the subform control is locked well. Even unbound controls are unusable. Here's an alternative approach: Locking bound controls on a form and subforms at: http://allenbrowne.com/ser-56.html This is a piece of code that leaves the form's AllowEdits property unchanged, but sets the Locked property of the bound controls instead. The unbound controls are therefore still usable. The code does lock the subforms too, but it accepts a list of controls to NOT lock. So, if you tell it not to lock your subform, it leaves it unchanged. "chris" wrote in message ... I have a form which I have locked for edits (in properties) to avoid accidental changes to data, and have place a command button on it to allow edits. There is a subform on this form which previously allowed users to add new associated records through the normal add record row at the bottom. However, when I chose to prevent edits on the main form I found that the add records row in the subform was greyed out. Clicking the command button to allow edits to the main form did not affect the subform. Has anyone got any idea why is might be happening and how I can overcome the problem? |
Thread Tools | |
Display Modes | |
|
|