window manager issue

Dec 4, 2012 at 9:23 PM
Edited Dec 4, 2012 at 9:27 PM

I have a strange issue with the window manager - has anybody else encountered this?

I have a Conductor<IScreen>.Collection.OneActive. This is the main view model (ie, shell). One of the view models it conducts uses window manager to open a new window that displays details about what they clicked.

The detail window is a form and I have CanClose overridden. When the user attempts to close, my logic runs - but if I callback(true) not only does the detail window close, the mainview model (The conductor) disappears to the background. So if you have my application open and it has focus above a couple other apps, it will hide behind all of them.
I don't have time to create a sample reproducing this, but if anyone else has experienced this, please let me know what I'm doing wrong.

This is the snippet I use to open the window:

 

 dynamic settings = new ExpandoObject();
 settings.WindowStartupLocation = WindowStartupLocation.CenterOwner;
 settings.ResizeMode = ResizeMode.NoResize;

 var iconUri = new Uri("pack://application:,,,/Icons/windowIcon.png", UriKind.RelativeOrAbsolute);
 settings.Icon  = BitmapFrame.Create(iconUri);
 _windowManager.ShowWindow(detailScreen, null, settings);
Dec 4, 2012 at 10:28 PM

Instead of ShowWindow you might want to give ShowDialog a try, you might even have to roll your own now close strategy, to catch the window if you are not wanting Dialog type behavior.

Dec 5, 2012 at 2:15 PM

Yeah, I can try ShowDialog - but in the end, I don't want dialog type behavior. I wish I knew exactly what was causing this odd behavior. I can dig into the CM window manager, but as you suggest it is probably easiest to roll my own close strategy. Thanks for the reply.

Dec 5, 2012 at 2:20 PM

Have you tried calling Activate on the view-model whose view should be selected, once the additional window is closed?

Unless you explicitly activate the previous shell, I suppose that the framework does not know that something has to be activated back after the conducted view-model is deactivated.

Dec 5, 2012 at 7:01 PM
Edited Dec 5, 2012 at 7:02 PM

I will play around with activation and see.

An interesting note that I forgot to mention - this only happens when there is a dialog box displayed over the detail screen. The user opens the detail screen from the main view model and when they close it my dirty checking logic runs and if the detail screen is dirty a standard Yes/No/Cancel dialog box appears. If the user presses Yes Or No, I invoke callback(true) and that is when the detail screen disappears and the main view model loses focus and goes to the background. If I minimize all my other applications, it is still there - but behind everything. If the form is not dirty, no dialog is displayed and callback(true) is invoked without any other code and in that case, the main view model does not go to the background and everything works as expected. It's bizarre. :) Oddly enough, I had a similar problem once in WinForms. 

 

 

 public override void CanClose(Action<bool> callback)
        {
            if (!Security.IsDirty)
            {
                callback(true);
                return;
            }

            var dialogResult = MessageBox.Show("Do you wish to save your changes?", "Unsaved Changes",
                                               MessageBoxButton.YesNoCancel, MessageBoxImage.Question);
            switch(dialogResult)
            {
                case MessageBoxResult.Yes:
                    Save();
                    callback(true);
                    break;
                case MessageBoxResult.No:
                    callback(true);
                    break;
                case MessageBoxResult.Cancel:
                    callback(false);
                    break;
            }
        }
Dec 5, 2012 at 8:40 PM
Edited Dec 5, 2012 at 9:15 PM

Oh - and ShowDialog() works fine.

This seems to be very similar to what is happening:

http://stackoverflow.com/questions/10757625/why-does-closing-the-last-child-window-minimize-its-parent-window

Dec 5, 2012 at 9:37 PM

For those having the same issue, you can fix it by making sure the child window (detail in this case) is completely independent of any other window. Set the owner of the child window to null. I suppose this is some issue related to the Owner/Owned relationship that I don't really have time to dive into. I don't think it is anything CM is doing - especially after looking at the WindowManager source and seeing non-CM examples of similar behavior on StackOverflow. Unfortunately, I need to use CenterScreen instead of CenterOwner.

 

dynamic settings = new ExpandoObject();
settings.WindowStartupLocation = WindowStartupLocation.CenterScreen;
settings.ResizeMode = ResizeMode.NoResize;
settings.Owner = null;
settings.ShowInTaskbar = true;