A Microsoft Office (Excel, Word) forum. OfficeFrustration

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.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Using Forms
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

navigating to different records in a read only form



 
 
Thread Tools Display Modes
  #21  
Old February 1st, 2009, 06:46 AM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
tina
external usenet poster
 
Posts: 1,997
Default 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  
Old February 1st, 2009, 04:16 PM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
Marshall Barton
external usenet poster
 
Posts: 5,361
Default 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  
Old February 1st, 2009, 07:01 PM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
Paul
external usenet poster
 
Posts: 68
Default 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  
Old February 1st, 2009, 07:13 PM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
Paul
external usenet poster
 
Posts: 68
Default 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  
Old February 1st, 2009, 07:20 PM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
Paul
external usenet poster
 
Posts: 68
Default 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  
Old February 1st, 2009, 10:42 PM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
tina
external usenet poster
 
Posts: 1,997
Default 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  
Old February 2nd, 2009, 02:39 AM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
Gina Whipp
external usenet poster
 
Posts: 3,500
Default 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  
Old February 2nd, 2009, 04:37 PM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
Marshall Barton
external usenet poster
 
Posts: 5,361
Default 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  
Old February 4th, 2009, 08:23 AM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
Paul
external usenet poster
 
Posts: 68
Default 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  
Old February 4th, 2009, 08:26 AM posted to microsoft.public.access.forms,microsoft.public.access.formscoding
Paul
external usenet poster
 
Posts: 68
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 05:36 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.