Unexpected Window behavior

May 7, 2012 at 6:53 PM

I have an MVVM project using Catel and am using the GetService method on the ViewModelBase class to instantiate views and message boxes from my view model classes.  I am seeing some strange behavior when using the IUIVisualizerService and IMessageService to show modal windows and dialogs.

For example, I have my main window that has a command that opens a window for a view model (we'll call it Window A) by getting an instance of the IUIVisualizerService and then calling the ShowDialog method and passing in the view model for Window A.  Window A is displayed as expected.  So far so good.

Now I have a command on Window A that opens Window B also by calling ShowDialog on an IUIVisualizer instance.  When ShowDialog executes, Window B is shown but Window A is hidden (or maybe just pushed to the background).  Why is that?  In typical Windows programming Window A would be left open and visible on top of the main window in this scenario and Window B would be open and visible on top of Window A.

When Window B is closed, then Window A becomes visible again (or is brought back to the foreground).

The problem I'm having is if I use the IMessageService in this scenario to open a message dialog from Window A to prompt the user for input, Window A is hidden when the message dialog is open, but when the message dialog closes, Window A is not shown again like when Window B closes but remains in the background.  In this scenario the user is forced to click in the task bar to get back to Window A which is undesirable.

Is this a bug or by design?

Coordinator
May 8, 2012 at 7:20 AM

Never noticed this issue. Can you upload a small repro as an issue? Then we can take a look at it.

May 8, 2012 at 5:51 PM

I created an issue and uploaded a sample project.  Catel libraries will have to be re-installed in the app as I had to remove the packages folder from the solution to stay under the size limitation.

I think I may see what the issue is from looking at the source code.  In the Show method of the MessageService class, it is calling MessageBox.Show and passing Application.Current.MainWindow as the owner.  I think that by setting the owner to the main view window, it is bringing that window to the foreground, putting it in front of the child window that is currently open.

In a MVVM app where you only have one main window with controls in various regions, that isn't an issue.  If you are using an architecture where you open details windows as dialogs and then need to confirm actions via the message service, this is a problem.

Coordinator
May 10, 2012 at 6:56 PM

Issue should be solved for IMessageService, IPleaseWaitService and IUIVisualizerService.

May 10, 2012 at 7:46 PM

I greatly appreciate it!

Coordinator
May 10, 2012 at 7:46 PM

Just published a new nightly build via nuget.

May 10, 2012 at 8:47 PM
Edited May 10, 2012 at 8:53 PM

I downloaded the new nuget build (it indicated it was version 3.1 and was updated 5/10/2012) but it did not resolve the issue. 

Also, the issue I was having with the Expose attribute that you fixed still exists in this version.  The fix for the Expose attribute was in version 3.2 so perhaps that's a different branch of code?

[UPDATE] I just downloaded the latest source code and built it (version 3.2) and both issues are resolved in that version.

Coordinator
May 11, 2012 at 8:04 AM

Very nice to hear that :)

It is probably because Visual Studio tries to force the same version references. So, the references have changed from 3.1 to 3.2 (versioning, although NuGet says 3.1.[DATE]). Probably the paths are now pointing to the output directory instead of the nuget folders. Really annoying, but apparently the VS team thought this would be a nice feature.

Thus: triple check your references and their paths.