0

Trying to understand how best to handle a closing event.

If I have multiple workspaces open that have children that when closed, may return data to the parent, which may mean the parent needs to process something, I am trying to figure the best way to stop the closing and return control to the parent workspace. (I can open different workspaces and have windows that are basically modal to the parent workspace.)

For Example: I have an account workspace that calls an address edit window. I close the app (from the window hosting the account workspace) in the middle of an address edit. I have the closing event step through the workspaces and if it finds a modal window open, it executes the canclose on that windows workspace.

Let's say the canclose prompts for a save and close, exit no save or cancel close. If it is save, the modal workspace sends the address back to the account workspace, which processes it. This usually leads to not continuing the close as this new data needs to be examined in relation to the account workspace and possibly saved there. I want the account workspace to take focus and I want the canclose that was initiated to get a false return.

Should I do the focus on the workspace as an event and just return false to the calling canclose?

I am confused on what happens sequence wise when I am running a process such as canclose and I fire an event off as to when the event code will actually execute in relation to the code that asked for the event.

Sean Airey
  • 6,352
  • 1
  • 20
  • 38
BRisley
  • 11
  • 4

1 Answers1

0

Instead of using your own mechanism (and possibly re-inventing the wheel), please first consider native FormClosing event. There you can Cancel closing or override CloseReason to a custom, non-cascaded value, for more a granular action tree.

Victor Zakharov
  • 25,801
  • 18
  • 85
  • 151
  • We handle capturing the close of a tab or the window, check our flag on the ws to see if it is dirty, if it is, then we call the process in the ws's datacontext viewmodel so that it can prompt the user about the action. That VM may save data to the db, or it may simply return data to its parent, that is why it needs to determine if it can close and what to do to properly close it. If it sends data back up the heirarchy, this involves calling a process on the parent ws vm to process the returned data. I want to stop the cancel and also do this return process and return focus to the parent ws – BRisley Nov 15 '12 at 14:51
  • @BRisley: you should be able to accomplish all this with above approach. I am using it currently for a production application that manages core of insurance management system. Cascaded unsaved changes will result in different prompts, and user can cancel at any step. – Victor Zakharov Nov 15 '12 at 15:12
  • How are you dealing with the prompt, are you allowing the prompt to do something that cascades up, or are you just cancelling the close event and leaving them at that workspace view? – BRisley Nov 15 '12 at 22:51
  • @BRisley: a user can answer `Yes`, `No` or `Cancel` for a prompt to `Save`. Sometimes it is not possible to `Save`, because validation fails, so only `Yes` and `No` are available (which are really `No` and `Cancel` in that context). Yes means save and close, No means don't save and close, and Cancel means don't do anything, go back to where I was. I don't do anything that cascades up so every window is responsible for itself. With how FormClosing works, if a parent is attempted to be closed, events will fire from the children. If cancelled at the child level, it will cancel the whole sequence. – Victor Zakharov Nov 15 '12 at 23:13
  • I have stuff that is dependent on returning values to the parent, they are not standalone. (We support different custom edits of details based on each site's rules, so we call different view/vm combinations and that data is used by the parent view.) The app is not opening any windows specifically in a modal mode, it just appears to be. We have routines that are called on the parent to process the return data when the child is finished and block activity on the parent. – BRisley Nov 16 '12 at 14:36
  • @BRisley: Returning values to the parent is fine, you can do it through custom properties, or a custom function which you call instead of `Show`. Modal or not - it does not matter. Just make sure you have proper window ownership in place. You still should avoid processing on the main form done by the child, because if you do, problems will appear down the road. – Victor Zakharov Nov 16 '12 at 14:53