Yes, you can turn off session locking by commenting out the SessionLock.StartSessionMonitoring() method within the InitApplicaton() method of he AppMain.vb file.

Thanks for the quick reply! I'll think of something for now to work around it (probably just disable the sessionlock key, if that is possible).

Yes, the CurrentUserChanged event will always fire after a session lock (even if the same user logs back in) because the LoggedInUser object is rebuilt each time (to gather the latest permissions from the server). 

So, the CurrentUserChanged event will always fire when the AfterSessionLock fires, but not vice versa.  The CurrentUserChanged event will fire in places where the AfterSessionLock will not fire.

Within that SessionLock method, we're enumerating through all of the open forms to remove all of the lock panels from them, so when you show an additional form that wasn't there when the SessionLock() method was called, the enumeration doesn't know what to do with it.  I'm sure I'll be able to reproduce it and get it fixed.

Well, a couple of things.



First, is the CurrentUserChanged supposed be raised if the SAME user logs back in (after a session is locked)? It seems to be. Which leads to the question, what is the difference then between the CurrentUserChanged and the AfterSessionLock events? They would seem to be fired every time a user logs back in after a session is locked.



Second, apparently I'm doing something to break session locking. It has to do with opening a form after the session is unlocked. This error occurs after the entire CurrentUserChanged event handler has run successfully. It breaks on the SessionLocking.LockSession line of code. I've isolated the issue to the opening of a form in the CurrentUserChanged event. If I let it run I get an error (shown below). If I continue on and view the SF error form, then close it, the form that is causing the problem is opened and functional. If I single step through it, there is no error. I tried Application.DoEvents(), but that didn't work (yep, that was a total shot in the dark).



Event chain (major steps that I know of):



-Click on Lock App toolstripbutton

-Click event calls the LockApp method

-LockApp method has single line of code: SessionLock.LockSession

-Forms are hidden, login form is shown

- Same user logs back in (stuff happens to login user)

- CurrentUserChanged event handler raised

- A switchboard form is shown (frm.Show)

- switchboard load event happens, loads treeview and user control into switchboard

- return from show, no errors

- return from event handler, no errors

- errors on SessionLock.LockSession



Variants:

- single step through Show method and load method, no errors

- after error and on line with error in VS, hit F5, SF error form shows, close it, form opens, no problems

- Comment out show line, no error





Here is the error I'm getting.



KeyNotFoundException

   The given key was not present in the dictionary.



Source : mscorlib



Stack Trace:

at System.ThrowHelper.ThrowKeyNotFoundException()

at System.Collections.Generic.Dictionary`2.get_Item(TKey key)

at MicroFour.StrataFrame.Security.SessionLock.LockSession()

at RAMS_MITA_2.ApplicationManager.LockApp() in D:\Projects\FoxSystems\RAMS.NET.StrataFrame\RAMS_2\RAMS_MITA_2\Modules\ApplicationManager.vb:line 240

at RAMS_MITA_2.MainForm.tsmiLockApp_Click(Object sender, EventArgs e) in D:\Projects\FoxSystems\RAMS.NET.StrataFrame\RAMS_2\RAMS_MITA_2\MainForm.vb:line 269

at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)

at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)

at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)

at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)

at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)

at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)

at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)

at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)

at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)

at System.Windows.Forms.Control.WndProc(Message& m)

at System.Windows.Forms.ScrollableControl.WndProc(Message& m)

at System.Windows.Forms.ToolStrip.WndProc(Message& m)

at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

That should work. I'll try it out. Thanks!

Your best bet in this case would actually be to handle the SecurityBasics.CurrentUserChanged event.  It fires whenever the CurrentUser object is changed (i.e. during the first login, as well as session locks).

When is this build going to be released?



Workarounds until then?



I have to handle this event to determine if the user or project has changed (project is again not a VS thing, but an app data thing), so I can redo permissions, reload menus, toolbars etc.

Yep, this is a known issue.  We added the method call to raise the event several weeks ago, we just haven't released a build since then.  It will be included in the next release.

The AfterSessionLock event doesn't seem to be firing. I'm attaching a sample application to demonstrate what I'm experiencing.