Telerik Forums / UI for Silverlight Forum / Window /

Wrong window stacking order

Telerik UI for Silverlight
Resources Buy Try

10 posts, 1 answers

hwsoderlund

419 posts

Member since:
Aug 2006

Posted 14 Jul 2009 Link to this post

I'm unsure whether this is a RadWindow- or a RadMenu-related bug, but here it is anyway: When opening a RadWindow from a menu residing in a parent window, the window appears behind the parent window rather than on top. The same problem occurs when opening a confirm dialog. I've created a sample project to demonstrate the bug:

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

1 posts

Member since:
Dec 2008

Posted 14 Jul 2009 Link to this post

I also discovered the issue and created a sample project to demonstrate it working on release Q1 but not in release Q2. I was just about to submit a post/bug report when I saw your post.

Here is a link to my sample project if its any help:
http://www.impulse123.com/TelerikWindowZOrderIssue.zip
Boyan
Admin

758 posts

Posted 15 Jul 2009 Link to this post

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.

hwsoderlund

419 posts

Member since:
Aug 2006

Posted 15 Jul 2009 Link to this post

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(); 
        
                    }); 
        
            }

Boyan
Admin

758 posts

Posted 20 Jul 2009 Link to this post

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.
hwsoderlund

419 posts

Member since:
Aug 2006

Posted 21 Jul 2009 Link to this post

I've found that in some situations my windows disappear anyway, despite the Dispatcher.BeginInvoke workaround. It's quite difficult to explain, but I managed to isolate the problem in a sample app. The code looks a bit elaborate, but that is because it is pasted from our production app, which is quite complex. I've included instructions in the sample app on how to reproduce the problem.

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

419 posts

Member since:
Aug 2006

Posted 22 Jul 2009 Link to this post

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
Boyan
Admin

758 posts

Posted 24 Jul 2009 Link to this post

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.
hwsoderlund

419 posts

Member since:
Aug 2006

Posted 24 Jul 2009 Link to this post

Ok, I'm sure you will sort it out eventually. It would be great if you could have a fix in place for the service pack, as I'm opening windows all over my app. The workaround you suggest is just not an option. Also, when using the static method RadWindow.Confirm I'm not even sure it's possible to manually reach into the opened dialog and focus on something. Or is there a way of doing that? Oh, and thanks for the points.
All the best, /Henrik
Answer
Boyan
Admin

758 posts

Posted 28 Jul 2009 Link to this post

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.

Wrong window stacking order

hwsoderlund

SentientPC

Boyan

hwsoderlund

Boyan

hwsoderlund

hwsoderlund

Boyan

hwsoderlund

Boyan