CODEWITHSUNDEEP
c#wpfwinforms
ADi
ADi

Reputation: 219

WinForm vs WPF .Close() event

WinForm

public Form1()
{
    Form2 obj = new Form2();
    obj.show(); //shows form2
    this.Close(); //exception crash: because constructor has not yet called `new Form1.show()`
}

In Winform

  1. 'this.close()' will through exception and crash (Cannot dispose object not initialized)
  2. if I don't call .close in Form1, and I close(X) the Form1, Form2 will also get closed because it is an instance within Form1

in WPF, same code:

  1. 'this.close()' will not through exception
  2. If Form1 is closed, Form2 will remain open as MainWindow.

Why is the Difference?

(Edit) I know in Winform I cannot close the same form in constructor because its not yet created, but how is WPF differ with it in constructor call?.

And what if I want the all children windows to get closed if the parent get closed, WinForm way?

Upvotes: 2

Views: 1303

Answers (2)

user1625871
user1625871

Reputation:

In WPF you don't manually dispose of WPF objects, they get garbage-collected when there are no more references to them.

As your Form1 have reference to Form2, ur Form1 will stay alive in background hiding the form on .close() untill you close Form2 as well.

You can destroy all objects on closing event of Form1, or you can force you application to Shutdown, which is not good idea unless you handle the unsaved data.

this is very through information on doing it How to exit a WPF app programmatically?

Upvotes: 1

Nimrand
Nimrand

Reputation: 1768

The difference is in how the the Close method for each class is implemented. Despite their similarities in function and appearance, System.Windows.Forms.Form and System.Windows.Window are two completely different classes built around two different architectures.

System.Windows.Forms.Form has been around since .NET 1.0, and is mostly just a thin, easier-to-use wrapper around the native precudral (i.e., non-object oriented) Windows UI library.

System.Windows.Window is part of WPF, which was introduced in .NET 3.0, was an attempt to build a modern UI framework on top of the CLI (rather than simply wrapping the older Windows UI library). So, System.Windows.Window's implementation may be completely different than that of System.Windows.Forms.Form. Additionally, though the operations available on these classes may be superficially similar, they may not be semantically identical. In this sense, Form.Close and Window.Close don't necessarily have exactly the same meaning.

Now, in this particular case, according to the documentation (http://msdn.microsoft.com/en-us/library/system.windows.forms.form.close(v=vs.110).aspx), you are getting this exception because "The form was closed while a handle was being created." If you unpack this statement a bit, what it means is that you made a call to the Close method before the window handle (HWND) for the form was created. This actually has nothing to do with the fact that you're closing the window in the constructor: the constructor for the Form class has already completed at this point. A Form object in .NET represents a native window in Windows OS, which is identified by a window handle (or HWND, which is the type name used in C/C++). However, because creating a window handle is an expensive process, the Form object doesn't actually create the handle until it actually needs it. So, the window handle for the form object doesn't exist until you call Form.Show, Form.HWND, or some other method that forces it to be created. If you had called this.Show() right before this.Close(), no exception would be thrown.

Why is this not the case in System.Windows.Window? My guess is that the Close method in System.Windows.Window is a bit "smarter" and simply skips the step of disposing the handle if it doesn't yet exist. Or, perhaps the window handle is created eagerly, unlike in the Forms implementation.

Whether this difference is entirely intentional is difficult to say. It's not entirely clear whether it makes sense to "close" a Window that's never been shown in the first place, and whether attempting to do so should cause an exception. Its a design choice. It's possible that Microsoft programmers now prefer the semantics of System.Windows.Window.Close over the less forgiving System.Windows.Forms.Close, but that making such a change would not be backwards compatible. Or, its possible no one really noticed or thought about the difference much.

Upvotes: 4

Related Questions