When using the ABL-Only WAIT-FOR, you can specify a "PAUSE n" phrase, which will let the WAIT-FOR time out/continue if the system is waiting longer than n seconds for user events without any being raised.
How would I achieve the same thing using the .NET & ABL version of the WAIT-FOR?
We work with financial systems and have the requirement that the system automatically log the user out and close the session if the user leave the terminal unattended for a prolonged period of time (or hide all windows and launch a LOCK window, which the user needs to unlock with his password).
We've been doing this since the very first system we did in 1992 on Progress v. 6 (READKEY PAUSE s-timeout. IF LASTKEY = -1 ....) but are now transitioning to the GUI 4 .Net and can't figure out how this needs to be done now.
We will never pass a system audit if we can't do this...
I've written a class which implements this functionality using a timer and the GetLastInputInfo API. The attached zip file contains the class (IdleTimer.cls) and a demo program (runme.p and Form1.cls). When you run the demo it displays the current value of ETIME and starts a 10-second timer. The ETIME value will be updated when you haven't moved the mouse or typed anything for 10 seconds. The displayed value shows how long (in milliseconds) it has been since the timer was started (so it will be the total of how long you interacted with the system plus 10 seconds). You can type in the edit box where ETIME is displayed if you want to interact with the program.
I put this together quickly so it hasn't been thoroughly tested. The usual fine print and disclaimers apply.
Thanks a lot, Matt. I will look at it.
Finding a way around long running operations (preventing the user from interacting) does still seem to be a problem in this case? But those should happen on asynchronous AppServer calls in any case, so I am not too concerned.
IdleTimer won't check for user interaction until the long-running operation ends. Then it will check whether the user interacted with the system within the timeout period (10 seconds in the example program). The way IdleTimer checks for user interaction is independent of the OpenEdge application. It checks whether the mouse was moved or any keys were pressed anywhere in the system. The fact that the OpenEdge application isn't responsive to input doesn't affect it. A long-running operation just prevents IdleTimer from doing the checking until the operation is over.
Another solution might be the ApplicationIdle component (www.codeproject.com/.../Application-Idle)
“Another solution might be the ApplicationIdle component (www.codeproject.com/.../Application-Idle)”
Which in the end is an implementation of the IMessageFilter interface.