Role base security is throwing an exception when the session lock timer fires. See attached.

Hi Larry.

I tried many different scenarios here to try and reproduce your problem and haven't been able to.
At this point, the framework is adding your open forms and their WindowStates to a dictionary, and apparently there is already a key of the same type added there.
Are you calling SessionLock.LockSession() based on a timer that could be triggering more than once, while on the second time the application would be already on a Locked state?

Cheers.

This is still happening on a random basis. One thought that came to mind is that the application contains a listview on the main window that is refreshed periodically (every 120 seconds). A timer starts a process on another thread that gets the data for the listview. When the thread completed event is fired, the listview is refreshed. Could this be causing a second session lock? There are no direct calls to sessionlock anywhere is the application except session locking is stopped just prior to displaying the logon form and restarted after the user logs in. This is done to prevent sessionlock from interfering with AppLifeUpdate.

Hi Larry,

If you are using and AppLifeUpdate controller in a form from which to check for updates, you could add the code to lock the session in the UpdateController.UpdateStarting event, this way if AppLifeUpdate discover an update and it is being applied, then stop the session lock session monitoring and after the update is applied, the application will be re-started normally.

Here the code I have in VB:

    Private Sub UpdateController1_UpdateStarting(sender As Object, e As Kjs.AppLife.Update.Controller.UpdateStartingEventArgs) Handles UpdateController1.UpdateStarting
        If (Not e.IsInitiatingController) Then
            '-- 5/6/2014: There is an issue reported by Larry Caylor at the SF forum in which he discovered that AppLifeUpdate could not closed
            '   the application properly before applying an update related to the SF SessionLock.
            '   http://forum.strataframe.net/FindPost32536.aspx
            SessionLock.StopSessionMonitoring()
        End If
    End Sub

Then you can remove prior calls to the SessionLock in your application.  If you are creating and Update.Controller via code, then you will need to add a Handle to that event.  This may fix the issue you are having with the RBS.

Edhy Rijo

Hi Larry and Edhy.

I have the exact same situation on my application, showing a listview that is refreshed based on a timer. The only difference, I think, is that I use a BackgroundWorker to process and interact with the form when the timer triggers. I also don't use the time span you do, mine refreshes automatically every 5 minutes if on a Local connection and every 10 minutes if connected through Enterprise Server. Even on longer intervals like mine, I also make sure that if the Timer triggers while the last trigger is still being processed, I won't let it go through and just exit it right on the first line of its Elapsed Event.

On my MainForm I have 14 Timers going on, all of them managed this way. I also have some that will trigger on shorter intervals, like one that will run every 10 seconds, which is used to "talk" to my Server module through TCP Sockets. I still don't get the exception you are experiencing there.
So I can test on my testing machine, which interval is set to the SessionLock you are having problems with?

Maybe what Edhy suggested could help too. I am not able to test the AppLife since I have an update procedure of my own, but maybe it is creating a second environment to be able to update the one already running and this is tricking the SessionLock to trigger on this one too and then the Keys will already exist on its list of open form.

Let me know if you would like me to test it in any other way.

Abraços.

I can’t be sure but it seems that the AppLifeUpdate and sessionmonitoring issues started with 1.7.7.1. I don’t know if anything changed in SFrelated to session monitoring with that release or if Microsoft released an OSpatch that may somehow be causing a conflict. In any event the AppLifeUpdateand session monitoring is not a problem since I know how to work around it byturning off session monitoring when processing an update. The real issue for meis trying to figure out why I’m getting the duplicate key error while the applicationis running. I can’t reliably reproduce the error, it just randomly happens.

BTW, how is SF2.0 coming along?

-Larry

It is possible that I broke something in some changes I made for 1.7.7.1.  We started using a WPF dialog for our login process with several of our applications.  A WPF Window certainly doesn't inherit from WinForms Form, so I had to add another interface ILoginFormExtended and tie the session locking into that.  Upon hearing of your problems yesterday, I made some changes to the SessionLock class to simply hide the forms when the session locks, so they don't stay on the task bar, only the login form is shown on the taskbar.  The side effect of that is that I no longer need a dictionary to store off the WindowState of each of the windows, so I changed it to use a list instead.  I'm not sure what could be calling LockSession() when it's already locked, but no longer using a dictionary, you certainly wouldn't get a duplicate key exception any more.

Hi Ben,

Now that i've got my development system working again I'd like to try the new session lock class code. I'm still getting the duplicate entry exceptions and haven't be able to track down what is casuing them.

-Larry