kill interactive uniface appli

Hi Dominique, if you use the timer only to invoke your check procedure but do not really care about users inactivity, I would recommend to activate this procedure based on UTIMER for the following reasons: - doesn't need any special ASN settings to enable the forced layout (no $TIMEOUT specified, no checks) - depending on a special keyword in the commandline, you can disable this forced logout in the startup shell - it allows intervals longer than 60 minutes Allover, much more flexibility with less demands on the ASN file used, Uli

Hi Dominique, If I understand correctly, you'd like to 'force' the user off (logoff) after the offices close. I presume all offices close at a certain time (like 5pm)?

We have a 'master' component being run from the application startup shell. 'yourcomponent' above is that said master component - thus when the timer kicks in - we end up in the ASYNC trigger of 'yourcomponent'... Then, apexit rules the day. Good luck, Knut

Thanks Knut But I saw in documentation that utimer needs urouter, which I'm not using So I think this solution doesn't suit to me Dominique

Hi Dominique, I think you have misinterpreted the info from the helpfile as "exclusive server" is a special context.

I had no problem using UTIMER in C/S without any UROUTER running, Uli

Hi Dominique, If you're using the UTIMER on the client side of an application then the URouter is not needed. Only when you want to use the UTIMER from a component that is running remotely in a UServer process then the URouter is required. The UServer does not have it's own message queue that could handle asynchronous messages. The queuing is down by the URouter. Hope this helps. Daniel

Hi Daniel, is there a Uniface-Function to get the time of inactivity? Uniface needs to know this value otherwise it could not fire the $timeout.   Norbert

Hi Norbert, No, not that I'm aware of. There is no public API for this (AFAIK). The timeout is handled in the main program loop of Uniface. Daniel

Hi Norbert,  If you were to design one, how would you reference it? From outside? Otherwise there would have to be activity on the client to check how long the client was inactive.  Regards,  Iain

Hi Dominique, Uniface has an historical built $timeout parameter to be defined into ASN file; with this parameter Uniface application is exiting closing connection after X minutes, with X in the range 1-60 minutes. IMHO this feature should be extended to larger values (I had requests up to 4hours = 240 minutes) but this is currently a wish. Starting with Uniface9 is available a new feature UTIMER; using this feature you can sets one or more timer(s) that can post messages to a specified component instance. You can find more info on UTIMER into Uniface Library at this link. Using UTIMER you can do whatever you like in your application with specific asyncronous timing. Regards, Gianni

as an addition to giannis post: while $TIMEOUT strikes after a given period of inactivity (at least that's what is documented), the UTIMER doesn't care what happens in between in the uniface application. Therefore most just use the utimer activation (each couple of minutes) to increment a counter (and fire action when limit is exceeded) AND have another operation resetting the counter which is called whenever a user activity is encountered. HIH, Uli

thanks I will use the $timeout, I need  to kill application when offices are closed , so I can test the hour and kill automatically so this is the easiest solution thanks for answers   Dominique

Hi Dominique, Uli / Daniel is correct - I do not run any urouter here at all - the UTIMER object runs in the client only. Knut

Iain Sharp said ... If you were to design one, how would you reference it? From outside? Otherwise there would have to be activity on the client to check how long the client was inactive.  ... Iain  

An option could be into "Async trigger" scheduled from $timeout with today range limitation to go over 60 minutes. Gianni

One option is a mechanism of accumulating consecutive $timeouts: Store timestamp of last $timeout and count invocations. When last invocation was $timeout period ( plus epsilon ) ago, then increment the counter. When the counter reaches the limit, start the action. Otherwise reset counter to 1 (as we have already one event).

to avoid misunderstanding: when last invocation was INSIDE lastTimestamp + epsilon then increment. To determine the epsilon, its good to log the invocations to get a feeling how reliable the $timeout beat is. When developing the concept, I used a $timeout of one minute and (depending on the systems other workload ) some (relatively large) differences. Much fun to try beating the $timeout counter. Uli

I use $timeout with 1 Minute. We close usersessions because of concurrent licenses.   In the "Asynchronous Interrupt"-Trigger of every Startup-Shell there is the following Code : ; ASYNC ; if ($result != "message")  activate "H_ONLINE".exec($formname, $result) endif   In H_ONLINE there is a Code like this:  ; Nach 90 Minuten inaktivität -> Exit  $TIMEDIFF$ = $datim - $LASTTIMEOUT$  $LASTTIMEOUT$ = $datim  if ($TIMEDIFF$[clock] > "00:01:20")   ; Der Anwender war aktiv   $INACTIV$ = 0  else   $INACTIV$ = $INACTIV$ + 1  endif  if ( $logical("Typ") = "PROD" )   if ($INACTIV$ > 90)    ; Zeitlimit erreicht, prüfen ob LOGOUT erfolgen muss    call LP_LOGOUT(90)   endif  else   if ($INACTIV$ > 45)    ; Zeitlimit erreicht, prüfen ob LOGOUT erfolgen muss    call LP_LOGOUT(45)   endif  endif   When the programs start we write a record to the database with Username Computername Application Starttime Endtime Menue Menuetime Each time the user calls a new menue the record is updated. In LP_LOGOUT we check, if the user is running more than one Application. If the user is working in a different Application, there is no need to Exit the actual Application because it is the same License he is using.   If we close the session, we execute an extern EXE which Shows the user that we closed the application for reason of inactivity.   I have the sneaking suspicion that the timeout is not Always fired when the user is inactiv. So Maybe UTIMER would be an alternative if you could request the time of inactivity.   Regards Norbert

gianni said

Iain Sharp said ... If you were to design one, how would you reference it? From outside? Otherwise there would have to be activity on the client to check how long the client was inactive.  ... Iain  

An option could be into "Async trigger" scheduled from $timeout with today range limitation to go over 60 minutes. Gianni  

Oh yes, that's how you would use $timeout to do the job, but the O.P. was looking for a function to query how long the session was inactive, and I was pointing out that the query itself would be activity (as would the loop it was in) so within a client, the answer would always be 0.  With the urouter in place, you can use the UROUTMON signature to query client status, which will return an idle time, but the client doing the query is never idle...    Iain