We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy.
Unfortunately, activation email could not send to your email. Please try again.

MainWindow unable to be Topmost

Thread ID:

Created:

Updated:

Platform:

Replies:

127546 Nov 22,2016 07:12 AM Nov 28,2016 07:32 AM WPF 3
loading
Tags: DockingManager
Erik Brunki
Asked On November 22, 2016 07:12 AM

Hello Syncfusion Team,

we have an application that has UserControls that are docked as pages to our MainWindow.
If, through double click for example, I make one UserControl floating, it rolls up to the top of all Windows.
This is of course desired and good.

The only nuisance is, that I cannot bring the MainWindow on top again.
The Floating Window will always be on top of the Main.

Multiple floating Windows can be on top of each other if clicked and change their Z-positions like expected.
Even in Nested Floating Windows this is no problem.

But all of these Windows will stay on top of the MainWindow.

I set "UseNativeFloatWindow" to true for all DockingManagers. 

Is there a variable I have to set  or another way I have overseen so that the MainWindow can be made on top if clicked (and of course be overshadowed if I click another window again)?

Regards
Erik

Ashok Kumar Murugesan [Syncfusion]
Replied On November 23, 2016 06:01 AM

Hi Erik Brunki,

Thanks for using Syncfusion products.

In our DockingManager, we have set the MainWindow as Owner of NativeFloatWindow. So NativeFloatWindows will be always on Top of MainWindow.
But we can restrict this behavior by changing the Owner of NativeFloatWindow as null. We have prepared the sample based on your requirement.
In this sample we have changed the owner of NativeFloatWindow as null. Please download the sample from the following link.

Sample: DockingManager

Regards,
Ashok Kumar M.


Erik Brunki
Replied On November 25, 2016 02:35 AM

Hello Ashok Kumar,

I am delighted to say, that your solution works just like intended, thank you!

But I have an important question, because this will be necessary for our own implementation.

Why is the timer important?
Why can I not put it directly into an DockingManagerStateChanged event? (I tried, it didn't work)
If you do not mind, I would like to know this in detail, so I can understand Syncfusion better and use it more effectively.

Regards
Erik

Victory Jessie Selvam D [Syncfusion]
Replied On November 28, 2016 07:32 AM

Hi Eric,

We cannot retrieve NativeFloatWindows in DockStateChanged event because it requires some time duration to generate the window. So we have tried to retrieve the windows using Timer in our previous sample. When NativeFloatWindow is generated, MainWindow will be deactivated, so you can use MainMindow's Deactivated event instead of Timer. We have modified the sample for the same and you can download it from the following link:

Sample: DockingManager

Regards,
Jessie

CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.

;