execute function when ActiveForm Changes (1 Viewer)

[JJSHEP89]

I'm attempting to execute a function every time the active form changes. i can get the name of the active form using Screen.ActiveForm property but I'm looking to automatically execute the same function each time it changes. I'm hoping to do this without adding a line of code on every form's event property since i have a bunch of forms and will be adding more.

The purpose of all of this is for a user login environment, where a user can log in using their credentials allowing them additional user privileges, such as edit and delete of certain records. I'm trying to set it up so that if the user is currently logged in a label showing "Welcome, John doe" will display in the header of each form, along with a logout button, and turn the visibility on of any specific buttons to edit and delete records. And if there is no user currently logged in, only the login button will show in the header, and all the buttons allowing for edits and delete's will be hidden.

i've set up global variables for the user id (varUserID) and the current active form (frmCurrent) but its like i need an OnChange event for the frmCurrent variable or something.

Anyone have any tips or hints?

 

[MarkK]

It doesn't make sense to me that this has bearing on the active form changing. If I had a new user log in, I would close everything that is open anyway, and start fresh. If I had to leave all the open forms open, I would enumerate them all and set them all up for the new user. Either way, I would never rely on being able to detect the change of the active form.
hth
Mark

 

[The_Doc_Man]

The problem is that events (which would detect the change in question) are specific to each form.

The way I always did this was when I first set up my DB, I knew I wanted certain events in common, so I built all of the events into a "template" form and copied it for each new form. Some of the formatting stuff and a lot of the event logging stuff were identical. The rest were anywhere from 60% to 80% correct because ALL of the forms had some functions in common - Close, Help, File Trouble Report, Reset/Undo. The bound forms also had Create and Update and Remove in common.

Yes, it is a definite pain in the toches to set up - but down the road I saved myself a TON of coding.

The event you probably want is either the form OnExit or OnEnter, either of which will come into play when dealing with form changes.

 

[JJSHEP89]

It doesn't make sense to me that this has bearing on the active form changing. If I had a new user log in, I would close everything that is open anyway, and start fresh. If I had to leave all the open forms open, I would enumerate them all and set them all up for the new user. Either way, I would never rely on being able to detect the change of the active form.
hth
Mark

think of it this way, I have a home screen with a series of buttons that opens up various forms. on this home screen i have a button for login. when pressed a new pop-up form opens prompting the user to enter their credentials. Assuming the user has successfully logged in, the login form automatically closes and the remaining home screen needs to change its login button to a logout button.

now this can be easily done for this one form but i would like to have a login button on each form so that my users as they dive deeper and deeper into the database and find something that needs to be updated or changed can do so without having to recreate all their steps to get back to that point.

I can make it work the way that Doc_man has described but its just not a pretty. i'm hoping the wealth of knowledge here may offer a more elegant alternative. Although my VBA has never really been all that elegant so im not sure why i'm trying so hard now...

 

[Minty]

But if they have Edit privileges just set them once on the home form globally for the database in the current session?
When a user logs in why would they have to login again just because they are on another form?

I think I'm missing something or possibly you are over complicating it? (Maybe)

 

[gemma-the-husky]

I think you will have to add code to every from to determine the sort of access you want the user to have, and to set up the form accordingly.

It isn't even quite as easy as just setting allowedits to true or false, because if you set it as false, you probably won't even be able to change the value of a combo box, which makes selecting records to view awkward.

Another way is to have two versions of each form - one for "normal use" and one for "read only" use, which might be quicker to do than the former example.

 

[isladogs]

My approach for this is as follows:
I have a Users table with various Boolean fields which are used to grant /deny privileges to different parts of the program.

Users login once only. To ask them to do so repeatedly would annoy your users.

Depending on their user status, the main form will show more/less or different buttons so that some users will not be able to access certain features. Anything they aren't allowed to use will be hidden or disabled.
Again, once they open individual forms, some items may be disabled or hidden for individual users.
I often organise this by grouping controls using the tag property.

Yes it does take a bit of time to set this up but it works well and users are happy.
If that's too much work, then you have to give everyone full access to everything. Up to you!

 

[JJSHEP89]

But if they have Edit privileges just set them once on the home form globally for the database in the current session?
When a user logs in why would they have to login again just because they are on another form?

I think I'm missing something or possibly you are over complicating it? (Maybe)

yes, you are missing something, although I may be over complicating it as well. My apologies, I try to limit the amount of typing i have to do but inevitably I leave out something important.

So we have some users that have their own personal workstations where they will be opening the application directly and first logging in, others are shared workstations by multiple factory and shop workers where they will be opening the main application and then further selecting an application within the main application and performing subsequent tasks within that environment. I would prefer if the user's didn't have to go all the way back to the home screen to log in, rather just log in within the application they are currently in.

I think you will have to add code to every from to determine the sort of access you want the user to have, and to set up the form accordingly.

It isn't even quite as easy as just setting allowedits to true or false, because if you set it as false, you probably won't even be able to change the value of a combo box, which makes selecting records to view awkward.

Another way is to have two versions of each form - one for "normal use" and one for "read only" use, which might be quicker to do than the former example.

Most of the forms are read only and I would have a pop up that would be used to edit or add new information, I have an audit trail set up so that any changes made to data are tracked so i just add that code snippet to any writable forms. I've set a global variable to the userID so that if someone is logged in it will toggle the visibility of the buttons used to access the form. this way its only the buttons visibility property that changes not any text or combo boxes etc. on the form.

My approach for this is as follows:
I have a Users table with various Boolean fields which are used to grant /deny privileges to different parts of the program.

Users login once only. To ask them to do so repeatedly would annoy your users.

Depending on their user status, the main form will show more/less or different buttons so that some users will not be able to access certain features. Anything they aren't allowed to use will be hidden or disabled.
Again, once they open individual forms, some items may be disabled or hidden for individual users.
I often organise this by grouping controls using the tag property.

Yes it does take a bit of time to set this up but it works well and users are happy.
If that's too much work, then you have to give everyone full access to everything. Up to you!

This is essentially what I am looking to do, just to clarify, i'm not actually asking them to login multiple times, i'm just wanting to give them the option to login on multiple forms.

Its essentially one database application in which there are subsequent applications for each department (Machine Shop, Production, Maintenance, Engineering, etc.) depending on the department will determine which environment the user will be in. I have a login option on the main form before anyone goes further into their departments which sets the Global variable "varUserID", which will stay logged in as they move within the database. but if a user has is already in a specific departments environment i want them to be able to login from there rather than go back to the home page.

Would you mind sharing a bit of your database and how you have it set up?

 

[Cronk]

I take the same approach as Colin, ie maintain a Users table with fields indicating access rights to individual forms, or generally their overall access (Read only, Edit, change lookup tables, super User who can add/change user rights).

If you have multiple users using the same PC without restarting Access, you will have to have then enter a password each time a form is opened. On top of this how are you going to force a form to be closed when the previous user has finished?

 

[isladogs]

This is essentially what I am looking to do, just to clarify, i'm not actually asking them to login multiple times, i'm just wanting to give them the option to login on multiple forms.

Would you mind sharing a bit of your database and how you have it set up?

If you want to proceed with the 'option to login on multiple forms' then my approach isn't relevant.
However, hopefully, you will change your plan

The attached screenshots are from a large & complex schools database
1. Users table design showing multiple Yes/No fields - there are actually more than this ... I said its complex - you might only need one or two such fields
2. Main menu form with 3 columns of buttons
a) Admin User version with all buttons visible
b) Standard User version with buttons missing in each column
c) Admin User version with lots of program features disabled - even more buttons missing
3. Part of the main menu form code that checks user status and program features in use then adjusts the buttons accordingly
There's a lot more code that didn't fit on the screenshot but it follows the same approach

A similar approach is used on some other forms to selectively show/hide or enable/disable certain controls according to user status or the program features in use.

Hope that's enough to give you the idea ...

 

[The_Doc_Man]

There is another thread in this forum about using global variables. Part of that discussion included the idea that SOMETIMES it is appropriate to have some globals that are visible to everything else.

So... what you do is have a General Module with code to do lookups of the user who is logging in. You keep the user's login data in the declaration area of that module, where all of the items that have to do with the user's session are PUBLIC (thus visible to every other part of your DB). Your login form calls this code to initialize the user session variables. Then the rest of your code just refers to the variables that were set up by the login process. And you NEVER change the contents of those PUBLIC variables once the login code is finished.

How does this work in a practical application? Let's say that one of the things a user can do is "Add New Inventory Item." On the form dedicated to inventory item actions, you have a button that says exactly that - Add New Inventory Item - and in that form's OnLoad routine, you have a test of the PUBLIC variable that REMEMBERS whether the user is allowed to do that. Then you have a simple IF/THEN/ELSE/ENDIF based on the PUBLIC variable. On the "Can Do" side, you make the button visible and enable it. On the "No Can Do" side, you make the button disabled and invisible. On those buttons representing something anyone could do? No test required.

Now multiply that by as many user-dependent functions as you have times the number of forms. Tedious - but you only do it once during form design.

 

[JJSHEP89]

If you want to proceed with the 'option to login on multiple forms' then my approach isn't relevant.
However, hopefully, you will change your plan

...

Hope that's enough to give you the idea ...

yes, thank you this does help. my goal is to eventually provide specific permissions to each user (no need for an editor of Production data to be changing engineering data) but that will come later on, so this will help greatly.

From what i'm seeing there doesn't seem to be a quick way to do this and I'm on some pretty tight time constraints already so I may need to save the login on each form project for another time.

There is another thread in this forum about using global variables....

So... what you do is have a General Module with code to do lookups of the user who is logging in. You keep the user's login data in the declaration area of that module, where all of the items that have to do with the user's session are PUBLIC (thus visible to every other part of your DB). Your login form calls this code to initialize the user session variables. Then the rest of your code just refers to the variables that were set up by the login process. And you NEVER change the contents of those PUBLIC variables once the login code is finished....

I like this approach... eliminates the need for multiple globals and can be replaced with just one.

 

[The_Doc_Man]

Actually, as many globals as you need. When I was doing this, I had something like 30 Booleans that were associated with a user's role and each user had ONE/ONLY ONE role. So I set all of the Boolean globals like

UserCanCreateServer
UserCanCreateUser
UserCanCreateUserGroup

and about 25+ other things.

Pain in the toches? Maybe a little bit. But you know what? Only had to call the code once per user login up front. So overhead time? Nil.

Since I was ALSO tracking logins, the same module that decided if you could access the DB at all would make a log entry on your attempt. That made usage records easy.