Active timer control causes cursor to jump in NumericUpDown control

[itg-assistant]

Andrew Hills asked 2018-03-07 05:34:41 UTC

Hi,

On my form there is a NumericUpDown set to 2 decimal places and when trying to enter a number the cursor will jump to the right so I have to backspace to get the cursor into the correct position.  Sometimes the cursor will stay put, other times it will jump back to the right again.  If I turn the timer off in my app then there is no problem.  The timer object runs in a class checking if the user is still active.

This problem is similar to: https://wisej.com/support/question/active-timer-control-causes-cursor-to-jump-in-masked-text-box

I'm running Wisej ver 1.4.65

[itg-assistant]

Frank (ITG) answered 2018-03-08 21:55:14 UTC

Hi Andrew,

I have logged WJ-8784 for the update problems in a NumericUpDown control while a timer is active.
We´ll check and inform you when it´s fixed.

Just curious though why you need to have a timer to detect user inactivity.
This should already be available through Wisej standard functionality.
Maybe you can shed some light on this ?

Thanks in advance.

Best regards
Frank

[itg-assistant]

Andrew Hills answered 2018-03-08 23:59:49 UTC

Hi Frank,

Thanks for that.

When a user logs into my app, I store some basic info about who is logged in for that session and also create a database instance and a logging instance to capture basic user activity and any errors. These 3 objects remain active during a session, mainly so I don’t have to constantly open and close a database connection which tends to slow things down with Dapper.

While the user is using the app, the timer object in the UserSession class keeps ticking away every second updating the last active date/time. If the user logs out using a logout button then the database instance, logging and user information is disposed of properly. But, if the user just closes their browser or page without actually clicking on logout, then those objects sit around in memory. So using that last active date/time, I can execute a linq query and find user sessions where the last active date/time has gone past 1 minute and dispose them properly. Each UserSession instance gets stored in a global ConcurrentDictionary so that’s how I can see who is logged in, what time they logged in and if their session is no longer active.

I am capturing the Application.SessionTimeout per user session, which will get triggered and dispose the UserSession object, but some users don’t want a timeout, they just want to leave their app open all day long then usually, just close off their browser window without logging out leaving that session info in memory, so that’s pretty much why I came up with this timer object approach to cleanup.

[itg-assistant]

Tiago (ITG) answered 2018-03-09 13:20:29 UTC

Hi Andrew,

As Frank said, there is a Wisej standard functionality. You can use the SessionTimeout event

Snippet

ApplicationBase.SessionTimeout += Application_SessionTimeout;

to setup a method that takes care of everything you mention

Snippet

private static void Application_SessionTimeout(object sender, System.ComponentModel.HandledEventArgs e)
{
}

You can read more about Session Expiration on

http://wisej.com/docs/html/Session.htm

[itg-assistant]

Andrew Hills answered 2018-03-10 05:17:15 UTC

Hi Tiago, I am capturing that Application.SessionTimeout event, but the problem is that I have users that don’t want a session timeout window appearing and want to leave the app running so in the SessionTimeout event I will set e.Handled = True for those users which prevents the session from actually terminating, so if that same user just closes the browser off without logging out of the app properly then the session remains active in memory. It would be good if there was some sort of event triggered when the connection is terminated, that way I could initiate a cleanup when that happens.

[itg-assistant]

Tiago (ITG) answered 2018-03-11 22:23:44 UTC

Hi Andrew,

When you set

e.Handled = true;

in the SessionTimeout handler, you can close the browser whenever you want. The application will stay alive and "in memory" until it expires. As the Session Expiration section states:

An "abandoned" session expires after twice the sessionTimeout value (in seconds) specified in Default.json or the default 120 second value.

(...)

*All the windows (pages, forms, ...) in the application are closed and disposed. (...) All the child controls are also disposed firing the **Disposed **event. *

In the attached sample, I also use the Form.Closed event and the Page.Disposed event to detected session expiration and application close/unload.

But the appropriate event is the Application.ApplicationExit.

Please have a look at the attached SampleSessionTimeout sample. The file LogFile.txt will store all the information you need. If I may suggest some steps:

• Run the application and minimize the browser as soon as the aplication shows up.

• Open LogFile.txt and refresh it after two minutes and keep refreshing it until you read the **SessionTimeout **message once or twice.

• Restore the browser, make sure the application is running and close the browser.

• Refresh LogFile.txt after two minutes and keep refreshing it until you read ApplicationExit message.

Please notice the MainPage Disposed message shows after the ApplicationExit message.

I think Application.ApplicationExit event answers your requirements.

[itg-assistant]

Andrew Hills answered 2018-03-12 01:38:22 UTC

Thanks Tiago, I didn’t know about the session expiration after session timeout is hit twice. As you mention from that excerpt, ‘All windows (pages, forms,…) in the app are closed and disposed’, would it be safe to assume that database classes that inherit IDisposable are also disposed in that same cleanup process? Also, I added a handler for Application.ApplicationExit but it doesn’t appear to get triggered after the session timeout expiration.

[itg-assistant]

Tiago (ITG) answered 2018-03-12 10:27:47 UTC

Hi Andrew,

Your question

would it be safe to assume that database classes that inherit IDisposable are also disposed in that same cleanup process?

Session documentation

If there other objects that are referenced but are not children, they will also be disposed when the GC and their finalizer kicks in.

Although it's a safe bet, I would use the logger to get the evidence.

Back to your comments to Frank's answer

When a user logs into my app, I store some basic info about who is logged in for that session and also create a database instance and a logging instance to capture basic user activity and any errors.

You can use the Session object like this sample

Snippet

internal static MyPrincipal AppPrincipal
{
    get { return Application.Session.User; }
    set { Application.Session.User = value; }
}

internal static MyIdentity CurrentUser
{
    get
    {
        return AppPrincipal.Identity.IsAuthenticated
            ? AppPrincipal.Identity as MyIdentity
            : null;
    }
}

internal static string CurrentUserName
{
    get
    {
        return CurrentUser != null
            ? "User: " + CurrentUser.UserName
            : "No user";
    }
}

replacing MyPrincipal and MyIdentity with your own classes of course. You can also store the database connection object on a session object. That way, it will be forgotten (and disposed if IDisposable is implemented) when the session expires. The same goes for the logger object, unless you prefer to use s static object that lives accross all sessions.

[itg-assistant]

Frank (ITG) answered 2018-04-09 21:38:13 UTC

Hi Andrew,

WJ-8784 is fixed in the latest Wisej release (1.4.79).

Best regards
Frank

[itg-assistant]

Andrew Hills answered 2018-04-09 23:25:25 UTC

Thanks Frank.