Wpf Question: No CloseReason?

[Andy]

Hi,

I'm trying to begin a new application in Wpf, and I'm trying to do
some similar things to what I have been in Wpf.

For example, in WinForms I have a base BusinessEditForm class. This
overrides OnClosing, which checks the CloseReason. If the reason is
anything other than ApplicationExit, I prompt the user if they would
like to save their changes if the business object being edited is
dirty.

I just let the window close if ApplicationExit is the reason, however,
because I only even call that method if a background thread determines
the I have locked out the application and all instances MUST exit
immediately.

I would like similar functionality in Wpf, but I can't figure out any
way to see if the user chose to close the window, or I've started a
shutdown.

Any ideas?

Thanks
Andy

 

[Chris Dunaway]

Hi,

I'm trying to begin a new application in Wpf, and I'm trying to do
some similar things to what I have been in Wpf.

For example, in WinForms I have a base BusinessEditForm class. This
overrides OnClosing, which checks the CloseReason. If the reason is
anything other than ApplicationExit, I prompt the user if they would
like to save their changes if the business object being edited is
dirty.

I just let the window close if ApplicationExit is the reason, however,
because I only even call that method if a background thread determines
the I have locked out the application and all instances MUST exit
immediately.

I would like similar functionality in Wpf, but I can't figure out any
way to see if the user chose to close the window, or I've started a
shutdown.

Any ideas?

Thanks
Andy

See this post:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2556734&SiteID=1

Chris

 

[Andy]

See this post:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2556734&SiteID=1

Chris

Ugh. Rather ugly for something that should be simple. Thanks.

 

[Andy]

Well, I'd like to point out that the only need you've stated for this is
an apparent issue of your own code deadlocking. Also, it's debatable as
to whether an application that's deadlocked can be consider it safe to
save user data.

Not a deadlock in the traditional sense, so I can't solve it in the
traditional sense. The problem I was addressing in WinForms was a
need to be able to force users out of my application. The normal flow
of OnClosing for forms in that application would check to see if the
object on the form was dirty and prompting the user to save changes
using a standard MessageBox prompt. Application.Exit would close the
application, but the window closing event could cause this MessageBox
prompt. If the user answers the prompt, the window would continue to
close (after saving, if needed) and everything would be fine. But the
user may not even be at the workstation, and I really need them out to
update the server side code.

If you really must deal with this sort of scenario, why not just have the
code that would normally call ApplicationExit go ahead and handle the
"save data" logic itself, rather than doing that when you detect that the
window is closing?

I should have probably mentioned this is an MDI application, and its
only the MDI children that are checking while they are closing. It
normally terminates when the main MDI parent is closed by the user.
The Application.Exit call would only happen on a special background
thread which checks the database to see if it should shutdown. Maybe
not the best setup, because it relies on me not calling
Application.Exit for any other reason, but I haven't been able to
think of any other good reason to do so because the the user closing
the parent would also terminate the application.

If I should be going another route to get this functionality, that's
fine. On a side note, I'm also hoping this functionality can be put
into a library. With WinForms, I have a class assembly that contains
a Form subclass... but it looks like VS won't let me use anything but
Window for the base class of Wpf forms. Maybe I should be making
everything a user control instead? So much to learn..

Thanks!
andy