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 |
#21
|
|||
|
|||
navigating to different records in a read only form
just to put my 2 cents worth in: going back to your very first post in this
thread, Paul, it sounds like you had the form allowing/not allowing edits as you wished, and the only stumbling block was being unable to use an unbound "combobox control to select different records" when AllowEdits was set to No. the simplest solution for this particular situation might be remove the combobox control from the form, and add it to a new unbound form, then add the original form to the new form as a subform. so you can set AllowEdits to True/False in the subform, without affecting the performance of the combobox control in the mainform. if you have VBA code behind the combobox control to select records, you should be able to adapt it to work on the subform's RecordSource. or you may be able to set the subform control's LinkMasterFields property to the combobox control name, and set the subform's related field as the LinkChildFields property, to pull the subform record(s) you want. hth "Paul" wrote in message ... Thanks for the sample code, Dirk. If I understand it correctly, it's a good way to control who can edit the records in a form if one group of users can edit all records in a form, and another group can edit no records in a form. I can use that in some situations, but in this particular one, I need to check the users' authorization for each record. This is a Project Management application, and I want the Project Manager and Team members to edit their own projects, but not other projects. I have some forms where users can only see their own projects, but in this particular form I want everyone to be able to see all projects, but only edit the ones in which they are on the mamagement team. And so I'm thinking the best way to do that is to check their authorization status in the following three events: 1. the form's Load event, 2. the form's OnCurrent event and 3. the selection combo box's Exit event Does that make sense? Paul |
#22
|
|||
|
|||
navigating to different records in a read only form
Paul wrote:
Two questions. 1. The expression "ctl.Locked = OnOff" - I haven't seen that before. Is that a toggle switch that turns the Locked property of a control on and off each time it executes? OnOff is an argument of the procedure. You specify True or False to lock or unlock the controls when you call the procedure, 2. Using the Tag property to identify which controls should be locked seems to be a great way to determine which ones are locked if you don't want to lock all of them. But if you want to lock or unlock all of them at once, wouldn't it be a valid, and possible simpler, approach to turn the form's AllowEdits property on or off, as per Dirk's suggestion? Right, but you have an unbound combo box that you do not want to lock, so you must do something about that one control. Like Dirk, I have not used AllowEdits in this context, so I am unaware of any unexpected idiosyncracies beyond the usual about AllowEdits having no effect if the record is already dirty. -- Marsh MVP [MS Access] |
#23
|
|||
|
|||
MISTAKE: navigating to different records in a read only form
Thanks for the link, John. I'm using A2003, so I'll take a look at it the
Security FAQ. |
#24
|
|||
|
|||
navigating to different records in a read only form
Thanks for your reply, Tina.
I did think of putting the combo box in a subform, but using Dirk's suggestion of setting AllowEdits = True in the combo box's Enter event seems to be working. Even if it were in a subform, I'd still have to check every new record to see if the user is authorized to edit it. Ok, full disclosure - there's another reason I wanted to avoid putting the control in a subform. I'm lazy, and every time I try put a subform camoflagued as a single control into a main form, I end up spending about 20 minutes wrestling with size and placement of the subform control to get it just right for appearance's sake. So from that standpoint, it's easier to just Allow Edits when you enter the combo box, and you're done with it. Marsh has raised a concern if the record is Dirty, so I'm going to ask him about that over in the other thread. Paul |
#25
|
|||
|
|||
navigating to different records in a read only form
Marsh,
I've put the code that evaluates the user's authorization status and sets AllowEdits in the form's Load and Current events, so I'm thinking the only way it could be dirty would be if someone else was in the process of editing the record when the user brought that record up. Is that correct? If so, it's not likely to be a problem, because of the large number of records, small number of users and low frequency of edits. |
#26
|
|||
|
|||
navigating to different records in a read only form
yes, a utilizing a subform is just one solution, and only better if it's
easier for you. just to clarify, i didn't suggest putting the combobox control in a subform, but rather in an unbound mainform, separating it from the original form which would become the SourceObject of a subform within that mainform. hth "Paul" wrote in message ... Thanks for your reply, Tina. I did think of putting the combo box in a subform, but using Dirk's suggestion of setting AllowEdits = True in the combo box's Enter event seems to be working. Even if it were in a subform, I'd still have to check every new record to see if the user is authorized to edit it. Ok, full disclosure - there's another reason I wanted to avoid putting the control in a subform. I'm lazy, and every time I try put a subform camoflagued as a single control into a main form, I end up spending about 20 minutes wrestling with size and placement of the subform control to get it just right for appearance's sake. So from that standpoint, it's easier to just Allow Edits when you enter the combo box, and you're done with it. Marsh has raised a concern if the record is Dirty, so I'm going to ask him about that over in the other thread. Paul |
#27
|
|||
|
|||
MISTAKE: navigating to different records in a read only form
Paul,
I found something I got from Dirk Goldgar back in 2005 that might even work better for allowing locking of controls. The below does not lok unbound fields or caculated fields but in combination with the Security table it might give you wnat you desire. I have a form frmLogOn and everyone has their one front end. My table consists of tblSecurity sSecurityID sSecurityLevel 1 Edit 2 View (or Read Only) 13 System Administrator frmLogOn has four fields, apAssociateID, apPassword, apLogOn, apSecurityID and goes invisible after they enter the correct Password. Their End-Users log on, password and security level is stored in tblAssociatesProfile. Then you can use this in the On_Current event of your form If [Forms]![frmLogOn]![txtSecurityID] = 2 Then fncLockUnlockControls Me, True Else fncLockUnlockControls Me, False End If ***** Copy in a module window but do not name module the same as the Function. Public Function fncLockUnlockControls(frm As Form, LockIt As Boolean) 'Lock or unlock all data-bound controls on form, 'depending on the value of LockIt: True = lock; False = unlock. On Error GoTo Err_fncLockUnlockControls Const conERR_NO_PROPERTY = 438 Dim ctl As Control For Each ctl In frm.Controls With ctl If Left(.ControlSource & "=", 1) "=" Then .Locked = LockIt .Enabled = True End If End With Skip_Control: 'come here from error if no .ControlSource property Next ctl Exit_fncLockUnlockControls: Exit Function Err_fncLockUnlockControls: If Err.Number = conERR_NO_PROPERTY Then Resume Skip_Control Else MsgBox "Error " & Err.Number & ": " & Err.Description Resume Exit_fncLockUnlockControls End If End Function -- Gina Whipp "I feel I have been denied critical, need to know, information!" - Tremors II http://www.regina-whipp.com/index_files/TipList.htm "Paul" wrote in message ... Thanks for the comments, Gina. As I mentioned to Dirk in my message of 1/31 5:34 PM, all users can edit some records in this form's recordset, but not all. Please see that message form more detail. I do have a question regarding your Security Table. Is this something you use as part of the built-in Access security? I've always avoided getting into Access Security because I've read that it "ranges from the labyrinthine to the inscrutable." If it's not part of the built in Access Security, and if it's simply a table you're using to establish user security levels, could you say a few more words about how you're using it? For example, are you using DLookup() in VBA to get into your security table to check authorization levels? Paul |
#28
|
|||
|
|||
navigating to different records in a read only form
Paul wrote:
I've put the code that evaluates the user's authorization status and sets AllowEdits in the form's Load and Current events, so I'm thinking the only way it could be dirty would be if someone else was in the process of editing the record when the user brought that record up. Is that correct? If so, it's not likely to be a problem, because of the large number of records, small number of users and low frequency of edits. No. The form would only be dirty if you allowed a user to edit a value or you have code that sets a value in the current record before you try to lock it. If this could happen, it would be a flaw in your logic or code. For example, setting a value in a bound control in the Current/Load event before setting AllowEdits. (This scenario should probably be considered a bug even without the use of AllowEdits.) Two different users/forms simultaneously editing a record is a different question. -- Marsh MVP [MS Access] |
#29
|
|||
|
|||
navigating to different records in a read only form
Oh, a separate main form. I didn't think of that. You're right - that
would work as well. Thanks for the idea. |
#30
|
|||
|
|||
navigating to different records in a read only form
Ok, now I understand what you meant.
This won't be a problem for me, because I'm not doing anything in code to set values before adjusting the AllowEdits property of the form. Thanks for the explanation, Marsh. Paul |
Thread Tools | |
Display Modes | |
|
|