This is a migrated thread and some comments may be shown as answers.

Wrong window stacking order

9 Answers 161 Views

Window

This is a migrated thread and some comments may be shown as answers.

This question is locked. New answers and comments are not allowed.

9 Answers, 1 is accepted

answered on 15 Jul 2009, 03:08 PM

Hello Guys,

Thank you for the applications that helped me reproduce the problem very fast. This is a bug indeed and it is happening only with RadMenu. You can check if you change the RadMenu with a Button that the Z order is fine.

We made some big changes to the way RadWindow works in order to have shared code with WPF version. The problem is that RadMenu gets the focus and that somehow breaks the Z order. We are still investigating what exactly is causing the bug so we can fix it. I hope we will be able to fix it for SP1, but can't promise.

Thank you for your reports, I have updated your Telerik points.

Sincerely yours,
Boyan
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

answered on 15 Jul 2009, 03:24 PM

I don't know if this will help you sort out the bug, but I have found a workaround. The windows stack correctly if you Dispatch the "Confirm" and "ShowDialog" calls (I'm now referring to the code in my sample project). So if you do the following, everything is back to normal, at least in the SL3 components, which is what I have installed now:

    
            private void RadMenuItem_Click(object sender, RoutedEventArgs e) 
        
            { 
        
                Dispatcher.BeginInvoke(() => 
        
                { 
        
                    RadWindow.Confirm("Really ?", null); 
        
                }); 
        
            } 
        
            private void RadMenuItem_Click_1(object sender, RoutedEventArgs e) 
        
            { 
        
                var win = new RadWindow(); 
        
                win.Content = "A new window"; 
        
                Dispatcher.BeginInvoke(() => 
        
                    { 
        
                        win.ShowDialog(); 
        
                    }); 
        
            }

answered on 20 Jul 2009, 03:33 PM

Hello Guys,

After some investigations we managed to locate the problem and it appears that it is not in RadWindow. I suppose you are opening the second window from event of a RadMenu or some other control (not Button). The thing is that our RadMenu for example when closing bring the focus to itself and when modal RadWindow opens the focus is taken from the menu and thus the bug happens. Currently we can't change RadMenu's behavior because if it doesn't gain focus it's behavior will be broken.

We found a very easy and nice workaround though. You just have to open the window with a small delay. Use this code:

    
            Dispatcher.BeginInvoke(() => {window1.ShowDialog(); });

This way everything is working fine. Hope that helps.

All the best,
Boyan
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

answered on 22 Jul 2009, 01:23 PM

I found another situation where the workaround is ineffective. I'm attaching to the DragEnded event of RadTreeView and immediately opening a confirmation dialog to ask the user whether he/she really intended to move the item. The confirm box is opened behind the main window. If I do Dispatcher.BeginInvoke it is exactly the same. The only thing that works is to start a dispatchertimer and wait for a few moments before doing RadWindow.Confirm. Pretty annoying workaround though, it requires quite a few lines of code. See the attached project for an example of the bug.

http://cid-cc43a90a79374ebd.skydrive.live.com/self.aspx/Public/SilverlightApplication32.zip

answered on 24 Jul 2009, 07:32 AM

Hi Henrik,

The problem with the DragEnded event is that RadTreeView has a delay on its drag and drop that exceeds the default Dispatcher.BeginInvoke and then the focus is again taken by RadWindow. Therefore, if you delay a bit more showing the Confirm window it is working fine. Here we can do nothing, because of the drag and drop implementation, whose delay can't be reduced.

About the first issue, It appeared that in Silverlight 3 Microsoft have introduced some changes related to focus of pop-ups and this is breaking our implementation of RadWindow. It appears that RadWindow is not gaining focus. You can modify your project and put a Button in the second window. If you focus the Button, before switching to another application it is working properly. We are now discussing how to change our implementation and will try to resolve this problem for SP1.

For now as a workaround you can set manually focus to an element in the second window after showing it. Thank you for your time and detailed examples. We will do our best to fix this focus issues. I have updated your account with 1000 Telerik points.

Regards,
Boyan
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

Accepted

answered on 28 Jul 2009, 09:20 AM

Hi Henrik,

After some discussions, we decided to change the implementation of our RadWindow. The logic will be that always the last window will be topmost and only a mouse click on other window will bring it to front. In this way It will be no longer possible to bring a RadWindow above a Modal window by Focus command executed. This will fix all the issues with incorrect Z order in the moment and you wont need Dispatchers or any other workarounds.

The change will be included in SP1 which will be next week. Hope that is acceptable for you.

Regards,
Boyan
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.