Mar 21, 2011 at 7:30 AM
Edited Mar 21, 2011 at 7:36 AM
The reason for this is due to the fact that Silverlight ChildWindow.Show() is not blocking as far as code goes. For example if I run this SL4 code
private void Button_Click(object sender, RoutedEventArgs e)
SomeChildWindow x = new SomeChildWindow();
String s = "the Cat";
I see the MessageBox "The Cat" first then the ChildWindow is shown. So Silverlights ChildWindow.Show is not truly blocking, even though when you show a ChildWindow from a users point of view it looks modal, so is more like what you get in WPF when you call
Window.ShowDialog() which is blocking and Modal. Now in WPF you also have Window.Show() which is also not blocking just like Silverlight, but when you call that the Window really is not Modal but back to Silverlight calling ChildWindow.Show() is not only
non blocking but also gives the appearance of being Modal. Come on Microsoft some API parity please.
In WPF land you also have ShowDialog() which is blocking and Modal. Both Window methods in WPF land return a bool dialogresult, which is something Silverlights ChildWindow.Show() just does not do.
The bottom line is the ChildWindow API is flying in the face of how things have worked since winforms v1.
As such in Silverlight you have to rely on callbacks to tell you about ChildWindow result, which you do not have to do in WPF as that comes out of the box. Very different scenarios actually.
So in WPF you have to use IUIVisualizerService, and in Siliverlight you have to use IChildWindowService.
Believe me I wish I did not have to do this, but until Microsoft make the ChildWindow API work the same as Window API, its what has to happens.