I need to both allow the user to log out (so another user can login) and handle session locking. I know the SessionLock.LockSession is used to do this sort of thing and session locking is on by default when a SF security project is created. What I'm confused about is what exactly happens. Here are some of the things I need to handle:



- session locks, user logs back in (this one is easy and already handled by LockSession)

- user logs off so another can log on (mostly used by testers), permission will likely be different.

- session locks, the user decides to close rather than unlock

- session locks, user has unsaved changes, decides to close

- session locks, another user logs on, original use has opened forms (maybe with pending edits), permissions might be different



So, suggestions on how to handle these cases?



Mainly, I'm wondering how permissions are handled with open form are shown when a different user unlocks the session, how to handle unsaved changes when a new user logs in or the user decides to exit first (of course, it might not be the user that was logged in that is exiting) and how to allow the application to close form a locked session.



Thanks!

You have already answered half of the problem yourself.  You know when you are in a locked session versus the initial login.  If you create a custom login form you can program any logic into that you would like....including calling some shared method within your application or your main MDI form to shutdown the forms and save changes.  Better yet, create a shared propety that has a direct object reference to the main form and expose a method to call.

Set this reference to the class when the main form loads or instantiates:

Next, create a method within the main form to shut down your children forms as shown in a previous post:

Now, in the custom login form, you can access the shared property to close the forms and shutdown the app.  Just add a button to your login form if you would like and enable it only for a locked session.  In the click call the shared property and public method:

hehe...like I said, I was pretty sure I was missing something pretty obvious!



OK, I get it now



One final question: is there anything special I should do when closing the app? Is using the "End" statement in vb enough? Do I need to do anything within the SF framework? Do I need to call Application.Exit()? *



* once again demonstrating my lack of .NET understanding

OK, I lied, I have another question (in addition to the one in the previous post).



Wouldn't the BeforeSessionLock event be the place to handle special stuff related to locking/logging in? I.e. I could set a flag in the MyApplication class (to continue with your example) to indicate that its session locking, I could save/undo changes to forms as needed etc (likely calling static methods in the MyApplication class). Then the login form would be cleaner and only have to deal with exiting. And would the best place to handle this event be in the MyApplication class? Am I really starting to get this!??!!?

This is the ultimate "SHUT DOWN NOW" command   Calling this will shut down the message pumps and logically exit the process.  Application.Exit() will not work (properly anyway) because you are running through an SF application. 

We always create a shared ShutDown method that does everything we need it to.  This was we can access from more than one location if need be.

If this meets your needs then sure.  The way I mentioned earlier would just give you the ability to shut down your application from anywhere if you needed to.

I believe you are

OK, I'm definitely getting it. I added an ExitApp method to my sealed static MyApplication class. I call it from the login form and will be calling it from any other place I need to shut down code (like the unhandled exception handler). I'm using BeforeSessionLock to handle any closing/saving/undoing of forms. AfterSessionLock to clear a flag that indicates that the session is locked (unless this is already available somewhere and I missed it).