Inactivity Detection on WebPage or Dialog

Targets Web
1

I need to have one page in an app be able to detect inactivity to auto close the page and return to a previous pages (a menu). The page also contains two dialogs that also need to have inactivity timeouts.

Before I implemented lots of logic I have been trying to figure out the best way to handle auto closing pages and dialogs based on a WebTimer. My “theory” is to have a timer count down an integer property and when it reaches zero it will force the page to close. If there is mouse or keyboard activity the integer property would be set to the original value to start counting down again. I figured the counter could tick pretty slow (maybe once per 10 seconds) and the overall timeout would be 5 minutes or 30 ticks.

I tried putting a KeyPress and MouseUp event on the main page but it seems that if those events exist they “intercept” the mouse click and keep the actual control (a button) from receiving the event. I figured I would use these events to “reset” the activity countdown timer without having to put the event on every single control.

Two Questions:

  1. Will I have to put logic in every control on the page that can interact with the user? Text fields and Buttons?
  2. Will I need to have separate timeout logic on the two dialogs on this WebPage and disable the timer on the WebPage when one of the Dialogs opens?
2

There’s already a mechanism for this.

http://documentation.xojo.com/index.php/WebSession.Timeout

3

I do use that to kill a totally idle session and logout completely.

I just want one WebPage to timeout and go back to a menu but not end the session. I will terminate the session with a much longer time.

To access this one screen needs a specific user that is in a group setting (home healthcare). I don’t want any other user to walk up and use the screen when it was opened by another user who did some work then walked away without exiting back to the menu.

4

You could always set the value lower for particular dialogs and then use a select case in the TimedOut event to determine what to do.

5

We trap the key, mouse and touch events for the built in system which would be much less processor intensive for your app. Otherwise yes, you’d need to implement all kinds of events and have all that extra traffic going to the server to be processed.

6

Just so I understand …

  1. I would set the “master” session timeout value at login.
  2. When I launched the WebPage in question I would set the session timeout to the desired shorter timeout.
  3. When I exit the WebPage in question (not as a timeout) I reset the session timeout to the “master” value.

I assume that the value of Session.CurrentPage will have the name of the WebPage or WebDialog that is active at the point of invoking the Session Timeout event.

Now the BIG question. If in the Session Timeout event I detect the current page is one where I want to return to the menu (and not end the Session) I could do a WebPage.Close and a WebPage.Show from the Session Timeout event and reset the Session Timeout value to the longer “master” timeout value? If it is not the page in question then I just do a logout as I do now.

I hope that makes sense.

7

Session.CurrentPage only holds WebPages. You’d have to track dialogs yourself. [quote=355010:@Mark Strickland]Now the BIG question. If in the Session Timeout event I detect the current page is one where I want to return to the menu (and not end the Session) I could do a WebPage.Close and a WebPage.Show from the Session Timeout event and reset the Session Timeout value to the longer “master” timeout value? If it is not the page in question then I just do a logout as I do now.[/quote]
Correct.