Re: Form.Close() - C# Discussion Boards

Salil Khedkar20-Sep-04 2:10

Salil Khedkar

20-Sep-04 2:10

Process the OnEndSession event. This occurs when the Windows session ends. Do what you need to do here and set a flag so that OnClose does what it needs (or dosen't need) to do. Wink | ;)

[Clarification: The events which I have described are MFC names for the corresponding Window events. Please find the .NET equivalents yourself. They must be something like: SessionEnding and Closing]

exhaulted20-Sep-04 3:15

20-Sep-04 3:15

All i can find in the help for OnEndSession relates to MFC and C++. Assuming i can use this in C#, what do i have to do?

Kev

Heath Stewart20-Sep-04 6:55

20-Sep-04 6:55

There is no OnEndSession method to override.

There is, however, the SystemEvents.SessionEnding event that you can handle. This works for all currently released versions of .NET, as well as the upcoming 2.0 Framework:

SystemEvents.SessionEnding += new SessionEndingEventHandler(OnSessionEnding);
// ...
private void OnSessionEnding(object sender, SessionEndingEventArgs e)
{
  // In your case, you probably don't care about the <code>e.Reason</code>
}

Implement your code in the handler, but do it fast. If you don't, your application will appear hung and Windows will prompt the user to kill it, which could leave your application data in an unsuitable state.

This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles]

exhaulted20-Sep-04 22:22

20-Sep-04 22:22

Well it sounded good but i still have the problem of the Close() method being called by windows when i attempt to log off or shut the PC down.

my code in the OnSessionEnding method is as follows

SaveSchedules();
Application.Exit(); //Bypasses the form.Close() method

Thats it, nice and quick. But, when the form is closing a call is made to CheckPassword() which is what is causing the problem. The end user will not know the password so they cant shut the scheduler down while the pc is running. If they log off / shut down the pc then i want the application to exit without checking the password.

Below is the offending event handler

private void Form1_Closing(object sender, System.ComponentModel.CancelEventArgs e)
{
//Write the details
SaveSchedules();

//Check for the password
if (!(CheckPassword()))
e.Cancel = true;
else
//Hide the notify icon
notifyIcon.Visible = false;
}

Thanks for all your help

Kev

Salil Khedkar20-Sep-04 23:30

Salil Khedkar

20-Sep-04 23:30

Kev, I think I told you to use a flag. Application.Exit() will still try to close the window hense call the handler.

Let me elaborate:

In Form1_SessionEnding()
Here you will do a SaveSchedules() and set a flag called bShutdownStarted=true

In Form1_Closing()

Here you will first check <br />
if(bShutdownStarted==true)<br />
// Do nothing<br />
else<br />
// CheckPassword() and other stuff

I am assuming that Form1_SessionEnding() will always be called before Form1_Closing() because logically it should happen so. Correct me if I am wrong. Kudos to Heath for the delegate example.

[A look at SystemEvents.SessionEnding MSDN page tells me what gets called first is not deterministic unless you override the WndProc function as per the example on the page]

exhaulted21-Sep-04 4:11

21-Sep-04 4:11

Salil,

2 things, firstly, Application.Exit() doesn't fire the form_closing event.
I tried calling Application.Exit from a button click and it just shut the app down without asking me for the password.

Secondly, Session Ending is called after Form_Closing so i can't simply set a flag.

Cheers

Kev

Heath Stewart21-Sep-04 5:28

21-Sep-04 5:28

No, Application.Exit doesn't fire the Form.Closing event, nor should it. Calling Application.Exit is the same as sending WM_QUIT to your message pump. When you close a form, you're essentially sending WM_CLOSE.

The fact that the events happen in the wrong order means you're not doing something right. You add a handler for the SystemEvents.SessionEnding in your form's instance (not in Main - your default entry point - since Application.Run is a blocking call). Set a flag then call Close. This sends WM_CLOSE to your window proc and your Closing event handler is called.

The previous post is correct then, and recommended was I was going to: use state variables. A simple bool would do.

The SystemEvents.SessionEnding event (not to be confused with SystemEvents.SessionEnded; if that's fired there's nothing you can do, really, at least as far as prompting for user input) handles the WM_QUERYENDSESSION message which is sent to application message pumps. This has nothing to do with WM_CLOSE or WM_QUIT. It simply notifies the window proc that a request to end the interactive session has been posted.

This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles]

exhaulted21-Sep-04 6:23

21-Sep-04 6:23

Heath, just to check i've got things right and we are both going along the same lines of thought.

I have a bool called closing in the form instance.

My forms constructor

public Form1()
{
InitializeComponent();
closing = false;
SystemEvents.SessionEnding += new SessionEndingEventHandler(OnSessionEnding);
}

Form1_Closing

private void Form1_Closing(object sender, System.ComponentModel.CancelEventArgs e)
{
//Write the details
SaveSchedules();

//Check the state variable
if (!(closing))
{
//Check for the password
if (!(CheckPassword()))
e.Cancel = true;
}
}

OnSessionEnding

private void OnSessionEnding(object sender, SessionEndingEventArgs e)
{
//Save the schedules
SaveSchedules();

//Set the state variable
closing = true;
}

Thats it, all the relevant code as far as i'm aware.
If the user closes the form manually then i want checkpassword to be called.
This works OK.
If the user enters the correct password, CheckPassword returns true and
e.Cancel remains false, the application exits nicely.

If the user logs off of the machine or shuts it down i don't want checkpassword to be called. To accomplish this, as i was advised in the previous posts i am using the state variable closing.
The closing variable is set to true in the OnSessionEnding method.

This is what i believe has been suggested but the CheckPassword function is still called. If i've misunderstood whats been said in the previous posts then please let me know so i can make the relevant changes.

Thanks for all your help and patience

Kev

Heath Stewart21-Sep-04 6:37

21-Sep-04 6:37

Again, you should call Close in your SystemEvents.SessionEnding event handler, after setting the state variable.

The problem is that canceling the WM_CLOSING notification message (setting CancelEventArgs.Cancel to true in your Form.ClosingEvent) won't affect the WM_QUERYENDSESSION notification message (your SystemEvents.SessionEnding handler). I would recommend implementing the same logic into both handlers:

private void OnSessionEnding(object sender, SessionEndingEventArgs e)
{
  e.Cancel = !CheckPassword();
}

The big problem here is that prompting the user takes time (mostly for the user to type their password, unless you're authenticating the password across some wire format or against a slow database; hardcoding it into the assembly is a bad idea since even a tool that comes with the free SDK can read it easily) - more time than Windows is willing to give it when shutting down. The application will appear hung and the user will be prompted to end the task (process) or cancel the shutdown. Inevitably, the user will blame your program.

This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles]

exhaulted21-Sep-04 22:44

21-Sep-04 22:44

I think we've still got our wires crossed, a little background might help.

This app is going to be run on PC's in the back offices of our shops around the UK. The staff in the shops are very limited to what they can do on the PC's and most of them don't know the difference between a monitor and a computer so the password being hard coded is safe enough.

The app will run in the system tray while the PC is on but, in certain cases one of our support guys might need to shut the app down manually. So they will restore the app from the system tray, click the cross and enter the password. This is all done without shutting the pc down.

In certain cases, i.e. when the support person in question can't dial into the box to take remote control they may just ask the user to shut down the pc. The way i have the app coded at the minute it prompts for the password when the PC is being shut down, this is what i'm trying to stop. The password is only there to stop the shop user from shutting down the application while they are logged in.

Hope that makes sense Poke tongue | ;-P

Kev

Heath Stewart22-Sep-04 6:57

22-Sep-04 6:57

exhaulted wrote:
I think we've still got our wires crossed, a little background might help.

I didn't know they were crossed to begin with. You asked for help and we gave it to you. The suggestions are sound if implemented correctly. What and why you need to do isn't really relevent. As I mentioned about hard-coding passwords, if it's for anything serious it's a bad idea. That implies that if it's not important, then hard-coding it may be fine. It was only a suggestion.

Again, though, what I mentioned before for implementation does work. Shutting down the machine posts WM_QUERYENDSESSION to the application before sending WM_CLOSE or WM_QUIT (it actually doesn't even send WM_CLOSE, IIRC). It wouldn't even make sense to do it any other way. I mean, why give applications a chance to cancel the shutdown if you close the main window (which in most applications terminates the main message pump) first?

This posting is provided "AS IS" with no warranties, and confers no rights.

Software Design Engineer
Developer Division Sustained Engineering
Microsoft

[My Articles]

yoaz20-Sep-04 2:56

yoaz

20-Sep-04 2:56

FYI:
.NET Framework 2.0 supplies a "FormClosing" event, which sends a "CloseReason" enum which seems to contain exactly what you need.
Alas, it's a beta Cry | :((

there are no facts, only interpretations

exhaulted20-Sep-04 3:10

20-Sep-04 3:10

That does indeed sound like exactly what i need, guess i'll have to try Salil's OnEndSession idea.

Kev

Nicholas Cardi20-Sep-04 4:50

Nicholas Cardi

20-Sep-04 4:50

You could look for the OnSessionEnd Message by over riding WinProc. Then programticly cause the application to close.

Hope this helps....

Forever Developing

exhaulted20-Sep-04 6:16

20-Sep-04 6:16

Thanks for that, seems like a possible solution but....

I've been looking at an example for overriding the WinProc and it seems
easy enough. The message ID is stored in the .Msg property.

Is there somewhere that lists all of the different windows messages and their equivelant .Msg values?

Cheers

Kev

Nicholas Cardi20-Sep-04 7:59

Nicholas Cardi

20-Sep-04 7:59

All of the windows messages are stored in the Windows SDK Header files.

Here is a link

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/wm_endsession.asp[^]

Here is the one you need

it is located in WinUser.h

private const int WM_ENDSESSION = 0x0016

Hope this helps...

Forever Developing