Proposal: Add ability to identify how long it has been since the last input
was received from the user. Justification: In each of the major commercial applications I have worked on in the past decade there has eventually arisen a request to do some action if the user has been idle for some period. Sometimes this is related to security--log out of the database if the user has been away from the keyboard for X minutes. Sometimes this is related to background tasks--during an idle period do some file maintenance. In the case of security, the approach of locking the entire workstation (with the OS screen saver and password) is not attractive because the champion or our application wants to have additional security and not be at the mercy of the local workstation setup. Also, the OS approach would require a separate OS account for each user and in a point-of-sale application they want to be able to leave the OS login as a generic account and have each clerk provide an ID to the application and have the application recognize if the user has gone away. One could keep track of user events internally, but that is a lot of extra overhead. Fortunately, Windows has an API for getting information about the last user input. Public API: UserLibrary>>getIdleSeconds obtains the millisecondClockValue associated with the last user input and compares it to the current time, returning a number of seconds since the last user event. The method handles the clock wrap-around that occurs when the 32-bit counter overflows. Implementation: UserLibrary>>getIdleSeconds " (Delay forSeconds: 5) wait. UserLibrary default getIdleSeconds. " | lastEvent current wrap | lastEvent := self getLastInputInfoTime. current := Time millisecondClockValue. lastEvent <= current ifTrue: [^current - lastEvent // 1000]. wrap := 2 raisedTo: 32. ^current + wrap - lastEvent // 1000 \\ wrap. UserLibrary>>getLastInputInfoTime | buffer flag | buffer := ByteArray new: 8. buffer dwordAtOffset: 0 put: buffer size. flag := self getLastInputInfo: buffer. flag ifFalse: [self error: 'Unable to get last input time']. ^buffer dwordAtOffset: 4. UserLibrary>>getLastInputInfo: anExternalBuffer " BOOL GetLastInputInfo( PLASTINPUTINFO plii <> // last input event ); " <stdcall: bool GetLastInputInfo lpvoid> ^self invalidCall |
"James Foster" <[hidden email]> wrote in message
news:[hidden email]... > Proposal: Add ability to identify how long it has been since the last > input was received from the user. James, I think this is quite a reasonable proposal, and I have no objection to it going into the base system. I'd like to see the abstraction implemented in the InputState class rather than in UserLibrary. In this case a trivial thing to address. It clearly must have taken you some effort to formulate your proposal, and thanks for that but it really isn't necessary to be quite so formal :-). A few words of why you think something ought to be in the base rather than in your own extension package, the code, and (critically) some tests will do the trick. Mostly in justification we would be looking for either (a) a common need and/or (b) great potential for a clash with extensions built by others. Regards Blair |
Blair,
Thanks for your response, and for your patience with my suggestions. I apologize for the "tone" of some of my comments. For what it's worth, I'm really enjoying the new tools. The IdeaSpace is taking some retraining on habits, but I can see it will be useful. And I really like being rid of the RichTextEdit widget for code. I'm still getting used to the text completion, and haven't (yet) discovered that I can't live without it. On the other hand, it certainly does give you parity with the best of the competing languages' code editors (for those who like to check-off a feature list). Have a good weekend, and thanks again for a wonderful product. James "Blair McGlashan" <[hidden email]> wrote in message news:[hidden email]... > "James Foster" <[hidden email]> wrote in message > news:[hidden email]... >> Proposal: Add ability to identify how long it has been since the last >> input was received from the user. > > James, I think this is quite a reasonable proposal, and I have no > objection to it going into the base system. I'd like to see the > abstraction implemented in the InputState class rather than in > UserLibrary. In this case a trivial thing to address. > > It clearly must have taken you some effort to formulate your proposal, and > thanks for that but it really isn't necessary to be quite so formal :-). A > few words of why you think something ought to be in the base rather than > in your own extension package, the code, and (critically) some tests will > do the trick. Mostly in justification we would be looking for either (a) a > common need and/or (b) great potential for a clash with extensions built > by others. > > Regards > > Blair > |
Free forum by Nabble | Edit this page |