navigating to different records in a read only form

  • Thread starter Thread starter Paul
  • Start date Start date
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 said:
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?
Click to expand...
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?
Click to expand...

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.
 
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
 
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.
 
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,

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 said:
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.
Click to expand...


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.
 
Oh, a separate main form. I didn't think of that. You're right - that
would work as well.

Thanks for the idea.
 
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
 
Thanks for the suggestions and the code Gina. In my situation, however, all
users can edit some records, but no user can edit all records in the form's
recordset. The approach I described in my message of 1/31/2009 5:34 PM
seems to be working well. The solution you suggested looks like something I
could use in a situation where some users can edit all the records in a
form's recordset, while others cannot, so I'll add this to my library for
use at a future date.

Paul
 
Back
Top