Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Auto Form Release

Status
Not open for further replies.

wsjames

Programmer
Apr 7, 2003
50
US
I am using VFP9.0 and attempting to automatically release a Form when there is no user input (keyboard or mouse) over a period of time. The form(s) have various objects (listboxes, textfields, etc).
- I've placed a Timer on the Form and enabled the form's
KeyPreview property.
- Within the Form's Click and Keypress properties, I
reset the Form's timer control.
When the Form is active and I Click on a Listbox item [repeatedly] the Form releases. This is not the result I hoped for. I would like the Form to stay active so long as the user is actively using the Form's objects.

I'm sure their is a more intelligent method to accomplish this. Help!
 
It's probably not enough to reset the timer in the Keypress and Clicks. You should also do it in the InteractiveChange, and possibly the GotFocus of each of the controls -- and perhaps the form's Activate.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business
 
I am converting an app from v2.6 and was hoping for a more global function like the old: #readclause timeout timeoutvar
 
When I've played with this sort of thing, I handle it in MouseMove and KeyPress. Set KeyPreview to .T. for the form and all keypresses will go through the form's KeyPress.

To handle MouseMove, add a method (BindMouseMove) in your base form class that binds the MouseMove of each control on the form to a form method (say, ResetTimer). Call BindMouseMove from the form's Init. Here's the code for BindMouseMove:

LPARAMETERS oObject

LOCAL oControl

IF PEMSTATUS(oObject, "Objects", 5)
FOR EACH oControl IN oObject.Objects FOXOBJECT
* First, drill down
ThisForm.BindMouseMove(m.oControl)

* Now bind this one
IF PEMSTATUS(oControl, "MouseMove", 5)
BINDEVENT(oControl, "MouseMove", ThisForm, "ResetTimer")
ENDIF
ENDFOR
ENDIF

RETURN

Call it from Init, passing the form:

This.BindMouseMove(This)

This'll work unless you're adding controls dynamically at runtime.

Tamar
 
Most of the time theory and practicality do not go hand in hand. What do I mean by that?
You want to shut down a form / app if there is no activity for ‘n’ minutes, what do you do if the user is editing a form and has not saved his changes? Before the shutdown; will you save the changes or revert them? If you save, What if there is field validation and it fires and the user is not at his desk, will you overwrite it and still save, if you revert and the users changes are not saved won’t that piss of the user if he has to reenter especially if it’s a lengthy or a complicated form?
Now you have to have a routine that also checks if the form has been put in an “Edit” mode to handle the above. There are hundreds of reasons why there could be no activity; the user may have gone to a meeting, lunch, get additional information or the bathroom…
If you go along with what has been suggested and put a timer and use the key press or mouse move on a form class, what if 2 forms have been opened, one for reference the other for input, there will be no activity on the reference form and after ‘n’ minutes it will close, how will you handle that? Don’t you think that might be annoying?
These are all cute tricks but have absolutely no value for your app. Be kind to yourself and let Windows time out and put the machine in hibernation mode, If the users find this annoying, it is not your app they will blame but the network administrator and the companies policies, this way when the user returns he/she just has to reenter their password and continue working in your app.
In designing an application always remember, it’s not about you, it’s all about the users. That is the golden rule which we developers sometimes forget. Always put yourself in their place and how your app can make their work easier. That is Value…If this is a 8-5 app, you want them to love working in it the whole day… Word of mouth is a priceless future sales tool especially if you have to provide references to your prospective clients.
I am sure this is not what you wanted to hear… I apologize. As you are “recreating” an app I just thought it may be good for you to consider the above points.
But if you still want to do this, put the timer etc in the _screen object, this way you can just shut the whole app down if there is no activity…
Just my opinion.

 
Tamar,
Thank you greatly for the solution. I am implementing now.

Mike,
Love your charts!

Imaginecorp,
Thanks for the insight. I completely agree with your points. However, in this case the app has a built password scheme. Access to certain forms require privilages determined by the AppAdmin. The user requested password and form timeouts pending user activity to limit risk of LowerLevel users from accessing PowerLevel user forms. App terminals are throughout their facility. Forced net logins is not desirable to them and PowerLevel users need access to all terminals.

The app is an engineering tool that acquires data from human and tool interface. The engineers setup recipes, characterize tool performance, upload & download system parameters etc. Because so many of their decisions are based on the app's configuration [hence] data analysis, they chose the timeout option as a result of the Engineers forgetting to logout...


Thanks again
 
Makes perfect sense... Sorry I misunderstood what you were trying to do...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top