Implementing an Inactivity timeout

[Dion Whittaker]

Hi,

I am trying to implement an automatic application logout function for my
application, ie if the user doesn't generate an event in the application
for some specified period of time the application will close all windows
(possibly including a stack allocated modal dialog) and return to a
login screen.

I have tried generating an exception when the timeout occurs, however
the stack doesn't unwind as I would expect, and if the top most window
is a modal dialog wxWidgets still ends up trying to delete it, and it
looks like the modal event loop associated with that dialog is still the
active loop.

I suspect what I need to do is to somehow tidily exit each modal loop
until I can get back to the main event loop.

Can anyone point me in the right direction on how I might implement this
type of functionality, or if it is even possible?

Thanks.
Dion

[Vadim Zeitlin]

On Sun, 22 Nov 2009 18:31:55 +0800 Dion Whittaker <dwhit...@cnsvs.com> wrote:

DW> I am trying to implement an automatic application logout function for my
DW> application, ie if the user doesn't generate an event in the application
DW> for some specified period of time the application will close all windows
DW> (possibly including a stack allocated modal dialog) and return to a
DW> login screen.

It looks like you've already solved the problem of detecting user activity
but just in case you didn't use this method, I'd like to mention that there
is wxApp::FilterEvent() which can be used to do it very easily.

DW> I have tried generating an exception when the timeout occurs, however
DW> the stack doesn't unwind as I would expect, and if the top most window
DW> is a modal dialog wxWidgets still ends up trying to delete it, and it
DW> looks like the modal event loop associated with that dialog is still the
DW> active loop.

There is probably a bug here somewhere...

DW> I suspect what I need to do is to somehow tidily exit each modal loop
DW> until I can get back to the main event loop.

I'm afraid wx doesn't maintain a stack of currently opened dialogs, it
only has a list of all top level windows (wxTopLevelWindows) which might be
enough to find the currently opened dialog in some cases but is definitely
not a general solution. Also, I think you might have problems dismissing
native dialogs (e.g. wxMessageDialog shown by wxMessageBox) like this.

IMO the best (although not the simplest...) way to implement what you want
is to use only dialogs which timeout automatically themselves, i.e. start a
timer when they're shown and call EndModal() on expiration. And avoid the
use of any standard dialogs. Or maybe you should even just avoid the use of
any dialogs entirely as it seems like your application should be running in
a kind of "unattended mode" anyhow and the dialogs are not really useful in
such case.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Dion Whittaker]

Vadim Zeitlin wrote:
> On Sun, 22 Nov 2009 18:31:55 +0800 Dion Whittaker <dwhit...@cnsvs.com> wrote:
>
> DW> I am trying to implement an automatic application logout function for my
> DW> application, ie if the user doesn't generate an event in the application
> DW> for some specified period of time the application will close all windows
> DW> (possibly including a stack allocated modal dialog) and return to a
> DW> login screen.
>
> It looks like you've already solved the problem of detecting user activity
> but just in case you didn't use this method, I'd like to mention that there
> is wxApp::FilterEvent() which can be used to do it very easily.
>

Yep, this is what I am using - thanks for confirming that this is the
right method though.

> DW> I have tried generating an exception when the timeout occurs, however
> DW> the stack doesn't unwind as I would expect, and if the top most window
> DW> is a modal dialog wxWidgets still ends up trying to delete it, and it
> DW> looks like the modal event loop associated with that dialog is still the
> DW> active loop.
>
> There is probably a bug here somewhere...
>

Playing around a bit more it seems as though the OS X (carbon) version
uses the same event loop for modal dialogs and the main event loop,
which is most likely the cause of my confusion.

> DW> I suspect what I need to do is to somehow tidily exit each modal loop
> DW> until I can get back to the main event loop.
>
> I'm afraid wx doesn't maintain a stack of currently opened dialogs, it
> only has a list of all top level windows (wxTopLevelWindows) which might be
> enough to find the currently opened dialog in some cases but is definitely
> not a general solution. Also, I think you might have problems dismissing
> native dialogs (e.g. wxMessageDialog shown by wxMessageBox) like this.
>
> IMO the best (although not the simplest...) way to implement what you want
> is to use only dialogs which timeout automatically themselves, i.e. start a
> timer when they're shown and call EndModal() on expiration. And avoid the
> use of any standard dialogs. Or maybe you should even just avoid the use of
> any dialogs entirely as it seems like your application should be running in
> a kind of "unattended mode" anyhow and the dialogs are not really useful in
> such case.
>
> Regards,
> VZ
>

It seems like wxTopLevelWindows is doing the trick at the moment.
Thanks for the help.
Dion