password login form with tags?

[vicsaccess]

i was following this thread a few weeks ago and ranman256 brought up a method he uses for password level access that intrigued me using tags. i hadn't heard or looked into tags yet so i started looking into them and i think I'm ready to try but how do i refer to command buttons with the below code from ranman instead of the cboform? i have about 10 different command buttons that need different levels of user access that i believe i can pass thru the tag property but is there a way to loop thru all the commands buttons and set the individual command buttons enable property to false? or to open a different page?
https://www.accessforums.net/showthr...light=property

vUsr =  Environ("Username")
if Dlookup("[UserID]","tUsers","[userid]='" & vUsr & "'") = vUsr then
   if Dlookup("[Pass]","tUsers","[userid]='" & vUsr & "'") = txtPassword then
       msgbox "Invalid password"
   else
        vRights = Dlookup("[Rights]","tUsers","[userid]='" & vUsr & "'") 
      docmd.openForm cboForm   'picked from a list
      if forms(cboForm).Tag ,vRights) =0 then
           docmd.close acForm, cboform
           msgbox "No rights to this form"
      else
            'check other rights here
      endif
   endif
else
   msgbox "User not on file"
endif

[Micron]

If you have set up a split db and made the front end an mde or accde, are you prepared to go into each form as required and alter the tags if the schema no longer fits the business model? What if you have to add another user level or shift buttons around from one level to the next? You will be looking too much redesign work AFAIC. Not saying his method is bad, but you should understand the ramifications of it first. I get the user levels from a table based on the logged in user (but I use the well known function fosUserName, not Environ). With that info, I set control visibility on form or db opening, using a Select Case block. Obviously, if I have to move one control from one level to the next, I have to move that code line from one case statement to the other, but that's all. So again, because this does not exempt me from having to edit the FE and republish it, it's not necessarily better or worse - it's a matter of which kind of changes you want to make. I suppose one could have a table of "tag like" values and control names in a table and do all sorts of things such as look them up, or load them into a form and check their values. That way, table maintenance would be the only work you'd have to do when changes are needed. Not much thought given to that idea beyond saying sometimes a solution might be more work than the status quo, so I don't know about that one. Just thinking on the fly here.

If I'm not mistaken, you saw my posted code today on how to loop through controls and look for a tag value, so the answer on how to do that is there
https://www.accessforums.net/showthr...9&goto=newpost

[vicsaccess]

Thank you for the reply Micron, yes it is a split DB and it is accde. First let me say that sometimes I'll post due to the need to fix something right now and sometimes my post are something that i saw posted that intrigues me that i would like to learn. In this case its kind of both. i currently do something similar to what you are describing using the fosusername and a table of user names and their levels but then on each form I start by calling a function on that form with a case select listing each level and the command buttons that will have properties enabled and visible set to false. this actually works great and gives me the ability to hide administrative forms from those that don't need it or for myself it unlocks all the ribbon commands, but this adds a lengthy function being called from each form upon form load. If I want to change or add the level of a button it involves going thru the code of each form, finding the right place in the function and hoping i got them all What i liked about ranman's use of the tag property was that i could set each command buttons tag property to its user level and change my select case to call the tag property and set enable and visible based on that. Actually my main confusion at looking at both ranman's code and yours was that both of you were calling text box's and combo boxes and was not sure how to call a command button. With a little more research this morning i found the msdn accontroltype enumeration at https://msdn.microsoft.com/en-us/lib...ffice.15).aspx and was able to figure out that i needed to be calling accommandbutton. so far here is what i have, in my test form i have 10 command buttons with different values in the tag property. Then i have a extra command button on the form to call this function

Private Sub test()
Dim ctl As Control
    For Each ctl In Me.FormHeader.Controls
        If ctl.ControlType = acCommandButton Then
            Select Case ctl.Tag
                Case Is = 1
                    ctl.ForeColor = RGB(255, 255, 0) 'yellow
                Case Is = 2
                    ctl.ForeColor = RGB(0, 0, 255)  'blue
                Case Is = 3
                    ctl.ForeColor = RGB(255, 0, 0) 'red
                Case Is = 4
                    ctl.ForeColor = RGB(255, 128, 0) 'orange
                Case Is = 5
                    ctl.ForeColor = RGB(0, 128, 0) 'green
                Case Is = 6
                    ctl.ForeColor = RGB(255, 255, 255) 'white
                Case Else
                    ctl.ForeColor = RGB(0, 0, 0) 'black
            End Select
        End If
    Next
End Sub

So far this is working great(please make sure you don't see anything wrong) and should not be hard to add the user level which is called and stored on each form as a hidden unbound text box during form load and then change the color change to enable and visible to false.
This should simplify my code a little but now I'm wondering what would it take to put this in a module? Can i control a forms controls from a called module? I'll keep researching, if anyone has any thoughts or help please post.

[orange]

vicsaccess,
You may find this list valuable (and there are others in left margin)
https://msdn.microsoft.com/en-us/lib.../gg278810.aspx

[Micron]

I guess I didn't understand the term "call a command button" 'cause I thought 'call it whatever you want'...
You meant 'reference', for which the answer was alluded to in the code of the linked post (Case acTextBox, acComboBox). What you needed was the correct reference to the control type you wanted to enumerate. I THINK Case = 1 would suffice, but what you have should work. That syntax is often used when making comparisions, such as Case Is < 100.
This link provides a list of constants you can use for control types
https://msdn.microsoft.com/en-us/lib...ice.11%29.aspx

OK, so I tend to nitpick:

This should simplify my code a little but now I'm wondering what would it take to put this in a module? Can i control a forms controls from a called module?

You "call" procedures, not modules. Yes you can, but if the procedure is meant to act only on one form, it's better to keep it with the form. Otherwise, tracing becomes more difficult, not to mention that you then need the complete object reference (not just Me). Any values set in the procedure can have a wider scope, thus they do not "die" unless you specifically deal with them on form closing, and could retain those values on subsequent form opening - again depending on how you code. I don't see a benefit for a one-off thing. If it's going to be referenced from several forms, then construct the procedure in such a way that you pass the form as an object and manipulate it there. Then have a corresponding procedure to clean up when the form closes.

[vicsaccess]

i think i may have done it. So far this seems to be working exactly like i envisioned. What i have is that when the form is loaded the user id and level is pulled from the user table and put into unbound invisible text boxes just because it makes it easier for me to have them there ready to go. When i call the function in the module I pass the user level. If i want a control to be user level specific then i add a tag number 1-4, otherwise it will ignore it.

Public Function userlevel(ul As Integer)
Dim frm As Form
Dim ctl As Control
Set frm = Screen.ActiveForm
    Select Case ul
        Case 1 To 3 '''1 is general employee order entry,2 is employee doing the job,3 is supervisor
            For Each ctl In frm.FormHeader.Controls
                If ctl.ControlType = acCommandButton Then '''only command buttons
                    If ctl.Tag <> "" Then '''look for controls with tag property,ignore the rest
                        If ctl.Tag <= ul Then '''only enable if tag property is <= user lever in table
                            ctl.Enabled = True
                        Else
                            ctl.Enabled = False
                        End If
                    End If
                End If
            Next
                DoCmd.ShowToolbar "ribbon", acToolbarNo
                DoCmd.NavigateTo "acnavigationcategoryobjecttype"
                DoCmd.RunCommand acCmdWindowHide
        Case 4 '''full rights for myself
            For Each ctl In frm.FormHeader.Controls '''only header
                If ctl.ControlType = acCommandButton Then '''only command buttons
                    If ctl.Tag <> "" Then '''look for controls with tag property,ignore the rest
                        ctl.Enabled = True
                    End If
                End If
            Next
                DoCmd.ShowToolbar "ribbon", acToolbarYes
                DoCmd.SelectObject acTable, , True
        End Select
End Function

the nice part for me now is that i only have one line of code per form and then add tags to the controls that i want user specific. Please take a look and see if anyone see's any bugs i didn't think about. Thank you all for helping.

[vicsaccess]

Thanks for the help.