MDI Tabbed interface and overlay window - Docking/MDI for WPF Forum

Posted 14 years ago by Robert Knight

Hi,
I am currently evaluating using the MDI for a project and have run into an issue.
My application involves a number of tabs, each containing a WinFormsHost. In order to display overlay graphics on top of these hosts I am binding another transparent windows position and size to the location of the host. The owner of these windows is my main application window.

This mostly works but I have a number of issues:

1. When a tool (or other window) is rafted it correctly appears above the overlay window. However if I then change tabs the overlay of the new primary tab appears over the tool window. This can be resolved by clicking the tool window and then back to the tab. I have implemented a couple of Activate calls in the tabbed host PrimaryWindowChanged to do this automatically but wondered if there was any alternative?

2. When a document, containing the WinFormsHost, is rafted the overlay window correctly follows the rafted window but after an initial move always appears behind it. I am assuming this is because the overlay windows owner is the main window. Have you any suggestions how I can resolve this?

3. When I have nested dockSites and rearrange my various tool windows the layout and position changed handlers on my overlay window are not getting called. Is there a general event I can hook into that indicates some change has occured to the layout one of the docksites and therefore force my overlay windows to reevaluate the position?

Thanks

Rob

[Modified at 07/26/2011 05:25 AM]

Comments (3)

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Robert,

The PrimaryWindowChanged event is only relevant for the MDI hosts. This cannot be used for the tool windows docked, auto-hidden, or floating.

You could attach a general handler for the Selector.SelectionChanged event. The tabbed MDI container and tool container are Selectors and will raise this event when the selected tab is changed. The event will bubble up, so you could attach the handler on the DockSite to handle all containers with in it.

For floating/rafting windows, you'd need to add a separate handler for each window. For this you'd need to create a custom class that derives from DockSite and override the CreateRaftingWindow method. You can then attach your handler there.

This would only give you changes to the selection though. Layout changes do not have a nice event that you can attached to. UIElements have a LayoutUpdated event, which you may be able to use. But I believe this is raised quite often so may end up being a bottle neck. We don't currently have an event on the DockSite that indicates the layout was updated.

Actipro Software Support

Posted 14 years ago by Robert Knight

Thanks for those answers that seems to make sense.

What I'm still not clear on is my point from question 2 where my overlay window always appears behind the rafting window. If the rafting window was a normal window I would set the overlay windows owner to be the rafting window. Therefore it would always appear above it in the z-order. Since rafting window doesnt have that property is there another way to achieve this?

Setting Z-Order Topmost is not an option as that wouldnt work with multiple rafting windows.

Any thoughts appreciated.

Thanks

Rob

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Rob,

I'm a little unclear on your question. The rafting windows are actual Window objects, unless you are using hosted rafting windows (which are more like adorners). The DockSite.CreateRaftingWindow gives you an opportunity to add your overlay window to the RaftingWindow (i.e. set the RaftingWindow as the owner, not the main window).

Actipro Software Support

The latest build of this product (v24.1.4) was released 29 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.