none
Silverlight 4 ChildWindow leaves parent disabled after closing

    Question

  • I didn't realize when I first started using a ChildWindow that just setting the DialogResult was enough to close the window.  I also added a call to Close() after I set the DialogResult.  This didn't cause any problems in Silverlight 3, but after upgrading to Silverlight 4 a child window will close correct the first time, but then the second time it closes but leaves the parent disabled.

     Here is some snippets that will reproduce the issue.  It was simply sovled by not calling Close() or not setting the DialogResult, but maybe is not correct behavior

     

    1    <UserControl x:Class="ChildWindowTest.MainPage"
    2        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    3        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    4        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    5        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    6        mc:Ignorable="d"
    7        d:DesignHeight="300" d:DesignWidth="400">
    8    
    9        <Grid x:Name="LayoutRoot" Background="White">
    10           <StackPanel>
    11               <Button Content="Test" Click="Button_Click"/>
    12               <Button Content="Test2" Click="Button_Click"/>
    13           </StackPanel>
    14       </Grid>
    15   </UserControl>
       
     
    1     public partial class MainPage : UserControl
    2        {
    3            public MainPage()
    4            {
    5                InitializeComponent();
    6            }
    7    
    8            private void Button_Click(object sender, RoutedEventArgs e)
    9            {
    10               ChildWindow1 window = new ChildWindow1();
    11               window.Show();
    12           }
    13       }
    
     
     
    1    <controls:ChildWindow x:Class="ChildWindowTest.ChildWindow1"
    2               xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    3               xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    4               xmlns:controls="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls"
    5               Width="400" Height="300" 
    6               Title="ChildWindow1">
    7        <Grid x:Name="LayoutRoot" Margin="2">
    8            <Grid.RowDefinitions>
    9                <RowDefinition />
    10               <RowDefinition Height="Auto" />
    11           </Grid.RowDefinitions>
    12   
    13           <Button x:Name="CancelButton" Content="Cancel" Click="CancelButton_Click" Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,0,0" Grid.Row="1" />
    14           <Button x:Name="OKButton" Content="OK" Click="OKButton_Click" Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,79,0" Grid.Row="1" />
    15       </Grid>
    16   </controls:ChildWindow>
    
     
     
    1    public partial class ChildWindow1 : ChildWindow
    2        {
    3            public ChildWindow1()
    4            {
    5                InitializeComponent();
    6            }
    7    
    8            private void OKButton_Click(object sender, RoutedEventArgs e)
    9            {
    10               this.DialogResult = true;
    11               Close();
    12           }
    13   
    14           private void CancelButton_Click(object sender, RoutedEventArgs e)
    15           {
    16               this.DialogResult = false;
    17               Close();
    18           }
    19       }
    
     
    Friday, April 16, 2010 4:42 PM

Answers

  •  A temporary solution that seems to work is to add this code to your childwindow class.

      

    Private Sub Window_Closed(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Closed
    
           Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, True)
    
    End Sub
     

     

    Tuesday, April 20, 2010 10:22 AM
  • This is what I found: do not call Close() if you already set DialogResult = true (or false); Or just call Close() without setting DialogResult.  If your main window need to check if you closed the window by using OK or Cancel, you should set DialogResult instead just calling Close(). 

    When you set DialogResult, the window will close itself. But if you call Close() after set DialogResult, you will see this problem. It always happens the 2nd time you open this Childwindow then close it again. The Parent will stay disabled.  The first time you open the ChildWindow and close it, it works fine.

     

     private void OKButton_Click(object sender, RoutedEventArgs e)
    9 {
    10 this.DialogResult = true;
    11 Close();
    12 }
    13
    14 private void CancelButton_Click(object sender, RoutedEventArgs e)
    15 {
    16 this.DialogResult = false;
    17 Close();
    18 }
    Tuesday, April 20, 2010 9:39 PM
  • I have the same problem.  Large app, silverlight 2, then 3, now 4, around 40 child windows in the project

    Latest tool kit
    Don't use dialogresult

    Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, True)

    solves the problem

     

    Thursday, April 22, 2010 10:38 AM

All replies

  • I have this problem also, but I only call the Close method on the ChildWindow. I have no idea how to fix it, it worked fine in 3. It also happens when the user clicks the X on the title bar which I do not explicitly call Close for. It happens for me the first time the ChildWindow is closed, but only on certain ones.

    Friday, April 16, 2010 5:20 PM
  • Hi Have you had a reply on this issue yet as i have the same issue ( my login is a child window , so no app after login ! )

    Monday, April 19, 2010 12:42 PM
  • No I haven't and I noticed today that even though I only set the Dialog result, once and a while the rest of the app still stays disabled.

    Monday, April 19, 2010 12:49 PM
  •  The weird thing is my login window works, just none of my other child windows, the only difference I know is that they are user initiated (opened in a click event).

    Monday, April 19, 2010 12:52 PM
  • HI,

       I am sorry , I copied your code and run a repro.

       In my test app, the childwindow will close with no side affects.

      Have you update your toolkit to the latest one? April 2010?

      Maybe you should try it.

    Bes tRegards

    Tuesday, April 20, 2010 2:04 AM
  • Hello,

     I do have the April 2010 Toolkit installed and un-installed the previous.  But I'm not sure that would have anything to do with this problem, my test application does not reference the Toolkit Dlls.  I just created a new standard Silverlight application in VS2010 Targeted at SL4 and added a child window and a couple buttons to open it.

    For the heck of it just now I set the target as SL3 and I have no problems also.  When you tested was your app targeting SL4?

    Thanks

    Brian

    Tuesday, April 20, 2010 9:03 AM
  • I upgraded my application to the newest Toolkit but it did not resolve my issue.
    Tuesday, April 20, 2010 10:05 AM
  •  Hi, I am having the same problem too.

     I went from the silverlight 4 and vs2010 beta to silverlight 4 and now I have the problem. I downloaded the latest toolkit but that did not solve the issue.

     

    I did make a new application, with just a button that opens a child window and that worked ok. I compared this with my application  I am working on and everything looks the same.

    Tuesday, April 20, 2010 10:20 AM
  •  A temporary solution that seems to work is to add this code to your childwindow class.

      

    Private Sub Window_Closed(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Closed
    
           Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, True)
    
    End Sub
     

     

    Tuesday, April 20, 2010 10:22 AM
  •  Thanks, that solves the issue for now. Smile

    Tuesday, April 20, 2010 10:42 AM
  • Yep, worked for me also...kinda hacky, but it does solve the problem.

    I do think there is some issue here that was changed with the SL4 RTW bits

    Tuesday, April 20, 2010 10:51 AM
  • Yes, there is definitely a bug somewhere. At least my application can run for now, unless it causes some other side effect that I have not experienced yet.

    Tuesday, April 20, 2010 10:59 AM
  • Yeah, Thanks for finding that...I'm going to sub class childwindow and that handler in it so I can just replace the base class of all my ChildWindows

    Tuesday, April 20, 2010 11:05 AM
  • HI,

      I just cant repro this issue , weird thing.

      I copied and checked every single line of code in your first post in the thread and made no change.

      I run it, then open & close, open & close, open & close.

      Is there something else I need to do?  I am glad you have find a workaround. But still I wish I could repro.

     Then I could report it.

    Best Regards

    Tuesday, April 20, 2010 9:23 PM
  • Well, it is sorta hard to reproduce because the project it happens in is so big. It was also upgraded from Silverlight 3 which may be a variable.

    Tuesday, April 20, 2010 9:28 PM
  • This is what I found: do not call Close() if you already set DialogResult = true (or false); Or just call Close() without setting DialogResult.  If your main window need to check if you closed the window by using OK or Cancel, you should set DialogResult instead just calling Close(). 

    When you set DialogResult, the window will close itself. But if you call Close() after set DialogResult, you will see this problem. It always happens the 2nd time you open this Childwindow then close it again. The Parent will stay disabled.  The first time you open the ChildWindow and close it, it works fine.

     

     private void OKButton_Click(object sender, RoutedEventArgs e)
    9 {
    10 this.DialogResult = true;
    11 Close();
    12 }
    13
    14 private void CancelButton_Click(object sender, RoutedEventArgs e)
    15 {
    16 this.DialogResult = false;
    17 Close();
    18 }
    Tuesday, April 20, 2010 9:39 PM
  • Yeah, thats the behavior I found also...but I've found that once in a while even just setting the DialogResult, it still would leave the main visual disabled.

    Min-Hong Tang would it be possible for me to send you my test solution that was having the problem?  Maybe that would help.

    Wednesday, April 21, 2010 8:56 AM
  • Hi,

       Yes, you can send it to v-minta@microsoft.com

       Thanks a lot.

    Best Regards

    Wednesday, April 21, 2010 8:41 PM
  • I have the same problem.  Large app, silverlight 2, then 3, now 4, around 40 child windows in the project

    Latest tool kit
    Don't use dialogresult

    Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, True)

    solves the problem

     

    Thursday, April 22, 2010 10:38 AM
  • Thanks a bunch all of you for this valuable information.

    I have been facing the same issue and this has taken away my considerable time debugging it.

    Finally calling

    Close();

    Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, true);

    worked for me. But not sure why using dialogresult hangs the Main application. Looks like we are missing something or there is bug.

    Thursday, April 29, 2010 11:14 AM
  • I have a new SL4 app that I'm building and this bug is occurring for me at what seem to be random times. It's difficult to duplicate it; all I have to do is click around the app trying different dialogs until it happens.

    I implemented the suggested fix of setting the RootVisual.IsEnabled property to True and it seems to have completely fixed the issue. What I did to implement was to sub-class the ChildWindow object and then insert the RootVisual.SetValue call in a method overriding OnClosed, then just have all windows in the app inherit from this sub-class.

    Sunday, June 06, 2010 6:38 PM
  •  This mostly works for me, except that I have a TreeView control that still remains disabled, even after setting RootVisual.IsEnabled to true. Has anyone found any other workarounds for this issue? Is the Silverlight team aware of this issue?

     

    UPDATE: Further investigation has shown that the TreeView actually does become re-enabled, however the TreeViewItems do not. My circumstance is slightly more complicated since I am actually creating a binding on the TreeViewItem.IsEnabled property inside of the TreeView.PrepareContainerForItemOverride method. Removing this binding allows the TreeViewItems to work correctly and re-enable after the ChildWindow is closed. I'm still working on finding a workaround where I can still maintain this binding on the IsEnabled property but still have the TreeViewItems become re-enabled after the ChildWindow closes.........anyone have any ideas?

     Another UPDATE:
    Changing the binding on the TreeViewItem.IsEnabled property from TwoWay to OneWay also fixes the problem and the TreeViewItems are correctly re-enabled. I'm honestly not sure why I had setup the binding as TwoWay in the first place.

    Friday, July 02, 2010 2:45 PM
  • Last I knew the MS tech couldn't reproduce the error from the code posted in this thread or from a sample project I sent him,  Since he couldn't re-pro it hasn't been elevated.

    Friday, July 02, 2010 3:05 PM
  • I missed putting the work around into a child window and found it today.  I put the child window in a class variable on the main page and then hide / show as required.  On this particular page I had to show / hide about 7 times before the problem occurred. 

    Friday, July 02, 2010 3:16 PM
  •  

    Last I knew the MS tech couldn't reproduce the error from the code posted in this thread or from a sample project I sent him,  Since he couldn't re-pro it hasn't been elevated.

    Are you sure? How can they not be able to reproduce this one?  This is so easy to reproduce. If you are sure, I can post a simple solution file for them to try.

    Friday, July 02, 2010 4:25 PM
  • I sent the tech a solution that did it everytime for me on 4/22 but I never heard back or saw a post on this thread.  I'd go ahead a post yours, maybe it will get someone to look at it again.

    Friday, July 02, 2010 4:37 PM
  • Works perfectly.

    C# Code:

    Place in your childwindow

    protected override void OnClosed(EventArgs e)
            {
     	        base.OnClosed(e);
                Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, true);
            }

    I also used  this.DialogResult = true;  instead of this.Close()

    Monday, July 19, 2010 10:39 AM
  • Adding my voice to the group of those who can reproduce this bug.

    The workaround does work for me. But any news on when we can expect a proper fix?

    Thursday, July 29, 2010 8:01 AM
  • I fixed it using this:

    public Lecturer()
            {
                InitializeComponent();
                this.GotFocus += new RoutedEventHandler(Lecturer_GotFocus);
            }
    
            //Add this to fix the background bug
            void Lecturer_GotFocus(object sender, RoutedEventArgs e)
            {
                Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, true);
            }
    That will at least solve the problem for all the ChildWindows on the one page. In my case, I'm using a Frame, so I solved it for all pages by placing that in the parent's constructor.

    Thursday, July 29, 2010 5:44 PM
  • Just a message to say that I also get the same problem.

    I hope the silverlight team can hear this and fix the pb for Silverlight 5. It's kind of a big bug !

    Sunday, October 31, 2010 1:50 AM
  • I am seeing this issue also.  Strangly enough, i have notice that if you put a breakpoint on the DialogResult = True/False or the Close() lines, and then just continue through once the debugger hits, the RootVisual re-enables just fine.  Remove the breakpoint and the RootVisual will not re-enable.

    Wednesday, November 10, 2010 11:12 AM
  • I also have this problem and it seems to appear on slower machines or virtuals.

    This could be a race condition.

    Thursday, November 11, 2010 12:20 PM
  • I had this issue when the user clicked the close button twice very fast. Disabling the button the first time the user clicks on it solved the problem.

    Friday, November 12, 2010 5:20 PM
  • ChildWindow w = new MyChildWindow();
    w.Closed += (s, eargs) => { Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, true); };
    w.Show();


    Friday, November 26, 2010 10:05 PM
  • Hello Estern,

    I have same problem as mentioned in threads.

    For me none of the method is working.

    :(

    Do you have any solution for SilverLight 3 ChildWindow issue which is disabling parent screen's controls.

    Tuesday, February 01, 2011 8:02 PM
  • Just thought I would mention that I am also experiencing this problem. In my case I have some controls with a two way binding on their isEnabled property and they are left disabled when the child window closes. Similar to an earlier poster, it will work if I step through with the debugger. The workarounds above do not solve the problem for me so I am using Prism's event aggregator to notify all my viewmodels to update their bound enabled value. I may also use the same mechanism to ensure IsEnabled reverts to the value it was before the childwindow was shown, rather than always setting it to true. This is surely the correct behaviour?
    Wednesday, March 30, 2011 8:47 AM
  • It seems to only happen to me when I bind the IsEnabled property of a control to a boolean property of another object.  This is when the ChildWindow controls screw up the IsEnabled property on the controls in my UI.  They probably didn't have the IsEnabled property of any of their controls databound when they were trying to reproduce the issue.

    Monday, August 29, 2011 9:48 AM
  • Overriding the OnClose method on the ChildWindow didn't seem to work me.  However, placing the code behind file for my MainPage.xaml file did work.  This bug really makes attempting to use MVVM fun.

    Monday, August 29, 2011 9:54 AM
  • I was actually not experiencing this issue in Silverlight 4 but we just upgraded our application to Silverlight 5 and this issue started occurring.  Adding "Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, True)" corrects it but we have a large application and it seems like a hack to do this on every child window.  Surely I can't be the only one experiencing this after upgrading right?

    Tuesday, December 13, 2011 11:32 PM
  • You certainly aren't the only one experiencing this.  I've had the issue crop up in SL3 and SL4.  The only reason I can't say that I've had the experience in SL5 is that my team hasn't moved to 5 yet.  I've had to use the same line of code you mentioned, and, yes, it does seem like a hack.

    Wednesday, December 14, 2011 6:54 AM
  • Thanks nl8nc it worked perfect.

    Thursday, April 12, 2012 9:39 PM
  • Also experienced the same today. Busy with a new project in Silverlight 5 using Dec 2011 Toolkit and all was fine and then while doing another round of testing it happened. I always just set the dialogresult to close a childwindow, but after getting the bug I tried Close() and it made no difference.

    Now using below code to get around the problem. This thread saved me valuable time.

    Application.Current.RootVisual.SetValue(Control.IsEnabledProperty, true);


    Wednesday, April 18, 2012 9:48 AM
  • I got this problem also, i was surprising why controls being disabled, anyway i just use the below workaround like mentioned here, and it worked:

    BOQForm cw = new BOQForm();

    cw.btnOk.Click += new RoutedEventHandler(btnOk_Click);
    bool tempIsEnabled = IsEnabled;
    bool tempIsSelected = IsSelected;
    //bool tempIsDesignEnabled = IsEnabled;
    //bool tempIsSelected = IsSelected;
    cw.Closed += (s, eargs) =>
    {
    IsEnabled = tempIsEnabled;
    IsSelected = tempIsSelected;
    };

    Wednesday, September 26, 2012 12:00 AM
  • (Y) Good!!


    Thursday, June 05, 2014 10:43 PM