Test for open popup forms

[Colman]

I have created a database that includes my own functionality that allows a user to log into the database. I now want to add a timeout feature that logs the user out after a period of idle. I have it working fine using the timer feature on a hidden form but I have one issue to overcome.

My timeout feature must not run if there are any popup forms open. Is there any way to detect this?

I should say that there are dozens of popup forms available to the user, all are modal.

Many thanks
Colman

 

[arnelgp]

Search on this forum isFormLoaded to check if a form is loaded/open. Use this to check at least a pop up form name is open and reset the time out if it does.

 

[Colman]

Thanks for your reply. I feel there are too many popup forms in my database to test each one by name to see if it is loaded/open (if that's what you mean). There are more than 100 of them.

Currently thinking I should ask the database for all loaded/open forms and test each of those to see if any are of a modal or a popup design.

Not sure how to test for that though.

 

[arnelgp]

copy this code in a Standard Module
this will do the checking for all
open form if there is ATLeast one
pop-up form:

Public Function IsAnyPopUpOpen() As Boolean
    Dim objForm As AccessObject
    For Each objForm In CurrentProject.AllForms
        If objForm.IsLoaded Then
            If Forms(objForm.Name).CurrentView <> acCurViewDesign Then
                IsAnyPopUpOpen = Forms(objForm.Name).PopUp
                Exit For
            End If
        End If
    Next
End Function

all you need to do is use it in your
timerform:

...
...
If IsAnyPopUpOpen() then
' there is at least one
' pop form open
' reset the timeOut
Else
' continue with timeout
End If
...
...

 

[Colman]

Thanks for the code arnelgp. I found the function was returning False both with and without a popup open. I think the 'Exit For' command meant that it only ever checked the first loaded form and then stopped. I inserted an extra If, then statement and it works now.

If Forms(objForm.name).PopUp Then
IsAnyPopUpOpen = True
Exit For
Else
IsAnyPopUpOpen = False
End If

 

[arnelgp]

Glad you made it work...

 

[Colman]

Hi Uncle Gizmo.

Thanks for your reply and for your wisdom. Levelling up sounds good. I'm in.

 

[Solo712]

I am surprised that you would want to distinguish between popups and non-popup forms. Since you are shutting down the app you can simply shut all open forms and then quit the app.

Public Sub CloseAllForms()
  Dim i As Integer, intErr As Integer, frm As Form, strForm As String
  On Error GoTo ErrExit
  For i = (Forms.Count - 1) To 0 Step -1
        Set frm = Forms(i)
        strForm = frm.Name
        ' Don't close the form requesting the shutdown (this is optional)
        If Not (strForm = "frmMain") Then
            DoCmd.Close acForm, strForm, acSaveNo
        End If
        ' Note any error that occurred
        If Err <> 0 Then intErr = -1
  Next i
  Exit Sub
ErrExit:
  ' handle errors or maybe just resume
  Resume Next
End Sub

Best,
Jiri

 

[arnelgp]

He dont want to shutdown when there is a pop up form open.

 

[Colman]

Uncle Gizmo, I wonder if we could pursue your comments a little.

My first database was for handling warranty returns for a manufacturer. Returned items were booked in and repair details logged and subsequently shipping details recorded and despatch paperwork generated.

If you said I should aim for 10 to 20 forms in that database I would think that would be too many.

My current database does the same returns functionality, far more comprehensively, and also does 30 or so other jobs. e.g. Change Control, Serial Number Generation, Equipment Calibration, Documentation Control, to name just four.

Are you suggesting that a single database should never handle this many jobs, or would you stick with 10 to 20 forms regardless of how many jobs it does, or would you revise your 10 to 20 forms proportionally?

Not arguing with you, just trying to get a sense of how far to expect to go with it.

 

[Solo712]

He dont want to shutdown when there is a pop up form open.

Ok, I didn't see that ....probably because I have written a shutdown-on-idle procedure myself and the restriction (no pop forms) makes no sense to me. It defeats the purpose of a forced shutdown (on a peer-to-peer network) which is to free resources held by unattended machines. One way to handle the shutdown politely is by issuing a two-minute (or so) warning to the user on a splash screen and inviting him to hit a key if he wants to continue.

Best,
Jiri

 

[Colman]

Hi Jiri. Thanks for your input.

I'm not wanting to close any forms and not wanting to close the app. I simply want a logged in user to be logged out after a short period (with a 1 minute warning) so that another user doesn't inadvertently use their log in to perform transactions. The reason for not wanting it to happen while a popup is open is that an open pop-up form could indicate a partially completed transaction which I would not want to interrupt.

Regards
Colman

 

[Colman]

Uncle Gizmo, many thanks for that. I do find your comments extremely interesting and helpful and look forward to seeing some videos if you get around to it.

Regards
Colman

 

[Gasman]

Tony,

I'd be interested in this approach, especially as I am using the emulated split form more and more, but how would I handle different number of columns, headers and the like?

I'm not sure it's possible or even desirable to specify how many forms a database should have. However it is common for forms to be spawned all over the place! That's the point really, try and repurpose a form so that it is used more than once.

Another place you see this "spawning of forms" is in the use of subforms. You have one subform on one tab with a particular record source, then an exact copy of the same form, but on another tab with another record source. You could very easily have five or ten subforms like this. All you need is one form (subform) and modify the subform's record source as you load up the main form.

In fact this is a good approach to adopt, because if you have a form with an active record source, then that record source is drawing data down. So if you had 10 tabs with 10 separate forms then you've got 10 hits on the data. A better approach is to endeavour to have the subform's record sources set to nothing "",only add a record source to the subform that is currently being displayed on the tab....

I've been meaning to do a set of videos explaining this!

 

[Solo712]

Hi Jiri. Thanks for your input.

I'm not wanting to close any forms and not wanting to close the app. I simply want a logged in user to be logged out after a short period (with a 1 minute warning) so that another user doesn't inadvertently use their log in to perform transactions. The reason for not wanting it to happen while a popup is open is that an open pop-up form could indicate a partially completed transaction which I would not want to interrupt.

Regards
Colman

I am sorry Colman, you have completely lost me. At any rate, I wish you good luck.

Best,
Jiri

 

[isladogs]

Colman,

From your last comment that I also don't understand, I'm wondering whether your users are sharing the same copy of the database or if it is split, that they are all using the same copy of the front end.

If either of these are true in a multi user environment, you are asking for trouble.

If the db is split with each user having their own copy of the front end, I think the whole point of this thread would become redundant

 

[Colman]

Hi ridders.

My database is indeed split with each station having its own copy of the front-end. I think what is confusing people is that each station is in a factory environment and in some instances it is shared by a number of people.

In order to restrict some database features to certain people, and also to allow names to be automatically recorded against some database transactions, I developed it to require that users log in with a password before they can do certain things.

This is not really important for anyone to understand except those using the database so forgive me for not explaining further.

Thanks to all for your help.

 

[Solo712]

Hi ridders.

My database is indeed split with each station having its own copy of the front-end. I think what is confusing people is that each station is in a factory environment and in some instances it is shared by a number of people.

In order to restrict some database features to certain people, and also to allow names to be automatically recorded against some database transactions, I developed it to require that users log in with a password before they can do certain things.

Hi Colman,
forgive me but my curiosity is picqued. First off, I don't understand your use of the term "transaction". When we speak of databases, "transaction" means something quite specific: see here https://en.wikipedia.org/wiki/Database_transaction

If you understand the term then you will also understand that making transactions dependent on logins does not make any sense and that ridders has every right to be confused. However, I have taken your use of the term "transaction" liberally, meaning perhaps some "action" performed on the database that is tied to the user log-in. Well if that is the case, ridders is correct also, because if a user begins an operation (on the shared back-end) and walks away from it while it is incomplete without the timer catching it in an inconsistent state and disposing of it automatically, is asking for trouble. Finally, you said:

I'm not wanting to close any forms and not wanting to close the app. I simply want a logged in user to be logged out after a short period (with a 1 minute warning) so that another user doesn't inadvertently use their log in to perform transactions. The reason for not wanting it to happen while a popup is open is that an open pop-up form could indicate a partially completed transaction which I would not want to interrupt.

So, again it sounds like some sort of lock is placed on part of the back-end which is login dependent, and which you don't want to interrupt simply on the suspicion there may be an active operation. But then of course logging the user out WHEN THIS IS NOT HAPPENING does not serve any purpose, or at any rate, any purpose that you told us about. Unless, of course, you want to tell us that your users log in with each others' log-in credentials.

Best,
Jiri

 

[Colman]

Let me first say that what I am about to say is not on topic for this thread.

I think there is some over thinking going on here but do accept that I mis-used the term 'transaction', using it to mean where someone has used the database to do something that added to or changed in some way, the back-end data. And no, I don't understand the true meaning of the term. I apologise for any confusion this may have caused.

I have a number copies of a front-end database, each one loaded on a separate PC located on various benches in a factory and all linked to a shared back-end database stored on a network server. Various people will visit each of the PCs from time to time, either to look at stuff or to do stuff. The front-end has lots of full screens that allow people to look at stuff and lots of popup forms that allow people to do stuff.

Like many data management systems I have seen, in order to do stuff, a user has to first log in with their password. To ensure this happens, the database won't allow popup forms to be opened when no-one is logged in, and when someone is logged in, only those popup forms that have been 'permitted' for that user, can be opened. All popup forms are modal. When they have finished doing the stuff on the popup, the user will close it or it will close automatically, depending on what it is they have done, and they should then log out of the database, but sometimes forget.

If someone forgets to log out, it is conceivable that someone else could come along and do other stuff without logging in themselves. If this happens, any records this person creates or changes, will appear to have been created or changed by the person who had forgotten to log out. It is this situation that my timeout feature now helps to prevent.

Now, if someone has taken the trouble to log into the database and open one of the popups, it implies that they had the intention to perform an operation. If they changed their mind they would close the popup. A popup form that is designed to allow a user to create a record will often have a number of unbound textboxes into which the user makes entries, and only when they have made a valid entry into each textbox, does the 'proceed' button become enabled. Clicking on the proceed button runs code that creates the record, based on the popup form entries, and the popup then automatically closes. At any time up to this point, the user may be distracted and leave the popup partially completed. In this situation, I do not want the database to close the popup as this would be annoying for that user when they return to complete the operation. I also do not want the database to log them out as this would allow the operation to then be continued but without recording who did it.

Please don't worry, there is no situation where the back-end data can be updated in an inconsistent state.

If I was designing the database from scratch, I may not design it quite like this, but having developed it over many years, this is how it has evolved, and it works.

I hope this makes things a bit clearer and satisfies everyone's curiosity.

Warm regards
Colman

 

[isladogs]

Without going into a long discussion about your whole approach, I would suggest that you make your database so all users have to login whether or not they intend to do a 'transaction'.

This would cover all the situations you describe without needing to deal with the issue described in this thread.
The database will be more secure and coding will be simpler.