Test for open popup forms (1 Viewer)

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

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.

Thanks. I'll get my coat.

Not quite sure how to respond to that ....

ridders said:

Not quite sure how to respond to that ....

Click to expand...

Well, you could give him a little shove out of the door....

ridders said:

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.

Click to expand...

You would think.

Best,
Jiri

Colman said:

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.

Click to expand...

Dear Colman,
when you come to AWF, be prepared to see some "overthinking" from people (some of them smart professional database developers) who may have issues with the approach you have taken. It's not a good form, and frankly I find it "rich", for someone who has yet to learn what "transaction" means in DBMS to accuse a responder on this forum of overthinking a problem. We are just trying to help, and most of us will know how to help when we post. So, please, show a little courtesy!

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.

Click to expand...

Now let's say for the sake of argument that I am ok with your approach to your problem. What would be the solution? Arnel told you you at the start to look for IsFormLoaded to get an answer to your problem. You replied


Problem is, Arnel did not register your info in OP that all your popups are modal. Now, if that is the case, you don't have to search for the name of the popup name. It's available to you.

So, now your timer routine only has to inquire whether a popup is loaded in deciding to logout the user. Ok? See now the reason for my curiosity? In case you don't, let me assure you that it wasn't because I was worried about anything.

Best,
Jiri

It's good policy to try and avoid using global variables. Basically there are safer alternatives.

See this thread I was party to a few years back:- https://access-programmers.co.uk/forums/showthread.php?p=566756

Uncle Gizmo said:

It's good policy to try and avoid using global variables. Basically there are safer alternatives.

See this thread I was party to a few years back:- https://access-programmers.co.uk/forums/showthread.php?p=566756

Click to expand...

Ok Uncle Gizmo that may be but that would be a different debate. I would agree that globals should not be overused. Here we are talking about a design where a workstation is left exposed to other people walking to it, and the designer is worried that they not "inadvertently" do something under someone else's login. How come I am the only one that finds this odd? Did not Colman think it possible that someone might walk up to the station and do something to the work that was entered and left hanging there ? Surely we are not talking normal conventional security precautions here.

At any rate, I withdrew the solution on globals because there really is one that would not require Colman to add the global setting in over a hundred places. My objection was to Arnel's loop was that it was redundant because you can easily get the answer directly by examining the Screen.ActiveForm property called Popup (since we know all popups are modal).

Best,
Jiri