Not sure I understand your question, it looks like you handle missing login or password. Maybe this is what you want (prevent all forms from opening if login was not activated)?
The way that I would prevent this is that the login form defines some data in a public variable in a general module OR in a TempVars entry OR some other generally visible structure. (Don't care which choice you make here - just that you make one.) THEN when a form opens, if the user information is faulty, have each form's OnOpen routine return without taking any other action than setting Cancel = 1 - which cancels the form Open activity. Remember that the OnOpen entry point is Private Sub form_Open( Cancel as Integer) - and it happens that it is passed by reference. Thus if you set Cancel = 1 you RETURN that 1 to the caller, which is Access. Access sees the 1 and aborts the form-open process.
The way that I would prevent this is that the login form defines some data in a public variable in a general module OR in a TempVars entry OR some other generally visible structure. (Don't care which choice you make here - just that you make one.) THEN when a form opens, if the user information is faulty, have each form's OnOpen routine return without taking any other action than setting Cancel = 1 - which cancels the form Open activity. Remember that the OnOpen entry point is Private Sub form_Open( Cancel as Integer) - and it happens that it is passed by reference. Thus if you set Cancel = 1 you RETURN that 1 to the caller, which is Access. Access sees the 1 and aborts the form-open process.
The other trick is if you have an opening form, have IT call the login form as a pop-up and, if the data returned from the pop-up is faulty, block the opening form. That blocks the whole application.
The other trick is if you have an opening form, have IT call the login form as a pop-up and, if the data returned from the pop-up is faulty, block the opening form. That blocks the whole application.
"Opening Form" What you mean? That my first form or what ?
if I'm right, then I have an "AutoExc" form where the form has loaded for user information.
Edit:
User Inforamtion like - Computer name and other Information, Computer OS, IP Address, Machine Name, Hard Disk information, Memory information, Logged in & Out Time etc.
If you have a form that takes over control of your user's experience, it is often defined via the File >> Options >> Current Database >> Opening Form path to identify a form that is the very first thing your user sees. Could also be a switchboard or dispatcher form. Many ways to say it, many ways to do it. But it is the form that comes up to provide your user with whatever face you want to show.
If this form tests whether your user provided good data, it is also capable of kicking out the user by setting its Cancel = 1 in the Form_Open routine when the user data is inadequate or just plain wrong.
If you have a form that takes over control of your user's experience, it is often defined via the File >> Options >> Current Database >> Opening Form path to identify a form that is the very first thing your user sees. Could also be a switchboard or dispatcher form. Many ways to say it, many ways to do it. But it is the form that comes up to provide your user with whatever face you want to show.
If this form tests whether your user provided good data, it is also capable of kicking out the user by setting its Cancel = 1 in the Form_Open routine when the user data is inadequate or just plain wrong.
You can put a lot of your logic in a general module, but the problem is "Me." doesn't work directly in general modules. The use of Me. is specific to class modules associated with forms or reports. The prefix specifically means "in the context of the form or report where the class module is attached" and has no meaning outside of that context. When you call a shared routine from a general module, the code in the shared routine is NOT in the caller's context. This shared routine can still see things declared "public" in itself and other general modules.
The next part of this is that having it in a general module does nothing - unless you CALL the module from the form/report class module. No call? No activation.
The way to make this work is to make this shared module have a way to know what you are trying to "touch" by passing in "objects" (usually by reference) to identify the target. Here's a simple-minded example.
Code:
Public Sub SetControls( UserRole as Integer, ByRef btn1 as Access.Control, ByRef btn2 as Access.Control, ByRef btn3 as Access.Control)
Select Case UserRole
Case 1 'admin
btn1.Enabled = True
btn2.Enabled = True
btn3.Enabled = True
Case 2 'manager
btn1.Enabled = False
btn2.Enabled = True
btn3.Enabled = True
Case 3 'payroll
btn1.Enabled = False
btn2.Enabled = False
btn3.Enabled = True
{other cases for other roles, if any...}
Case Else
btn1.Enabled = False
btn2.Enabled = False
btn3.Enabled = False
End Select
End Sub
Then when ready to use this, from each Form_Load routine use:
Code:
SetControls RoleNumber, Me.cmdF, Me.cmdH, Me.cmdP
Now all you need is a one-liner for each form.
If you have a lot more controls, there are techniques where you put certain keywords in each control's .Tag property (which can be a comma-separated list of words if you want). In that case, you would have a sweep of ALL of the controls of the form
The sweep might be like this:
Code:
Public Sub SetControls( UserRole as String, ByRef f as Access.Form )
Dim c as Access.Control
For Each c in f.Controls
Select Case c.Type
Case acTextBox, acComboBox, acListBox
If Instr( c.Tag, UserRole ) <> 0 Then
c.Enabled = True
Else
c.Enabled = False
End If
{other control types here}
End Select
Next c
End Sub
Then the final thing you do is manually list the role names you would set true in each control's Tag property. For example, for your admin-only, your tag would include Admin whereas for admin+ manager, you would include "Admin,Manager". Then when you call this,
Thank you very much, appreciated...
I already created the Module.
Code:
Private Sub Form_Load()
SetControls 1, Me.cmdHR, Me.cmdFile, Me.cmdPayRoll
'And tried it
ModCmdControl.SetControls , 1, Me.cmdHR, Me.cmdFile, Me.cmdPayRoll
And tried it
ModCmdControl.SetControls (1, Me.cmdHR, Me.cmdFile, Me.cmdPayRoll)
DoCmd.Maximize
End Sub
But not work, Have a message
"Argument not optional"
I have corrected an error in the second routine I showed you where I omitted the "Sub" declaration. My bad!
You put the Public Sub declaration - with the ByRef "formal" arguments - in the general module then use the call in each form's form_load routine with the actual control names.
I have corrected an error in the second routine I showed you where I omitted the "Sub" declaration. My bad!
You put the Public Sub declaration - with the ByRef "formal" arguments - in the general module then use the call in each form's form_load routine with the actual control names.
If you don't get a change when you have a different user, then whatever you did to log in that user didn't change the user role correctly (or whatever indicator you are using.)
No guarantees that I will look at the DB because I'm in the middle of a writing project.
If you don't get a change when you have a different user, then whatever you did to log in that user didn't change the user role correctly (or whatever indicator you are using.)
No guarantees that I will look at the DB because I'm in the middle of a writing project.
Yes, your guess is right. user role is not to find is correct. because I don't use the Dlookup as before. I find my mistake.
Its work.
Thank you very much for your kind information and find my mistake.
Glad I could help. The fun part of this is that it is low maintenance for adding users and actually not that hard to add controls. The problem becomes tougher if you add new roles.