Crash when docking

Docking/MDI for WPF Forum

Posted 2 years ago by Alexandre Grégoire
Version: 16.1.0633
Avatar

Some users of our tool have been reporting that docking certain windows makes our application crash. 

Here is the callstack

System.InvalidOperationException: The specified Visual and this Visual do not share a common ancestor, so there is no valid transformation between the two Visuals.
at System.Windows.Media.Visual.TransformToVisual(Visual visual)
at #P6i.#O6i.#M6i(DockHost #tm, Point #bVe, IHierarchyContainer #cwf)
at #P6i.#O6i.#M6i(DockHost #tm, Point #bVe, IHierarchyContainer #cwf)
at #P6i.#O6i.#M6i(DockHost #tm, Point #bVe, IHierarchyContainer #cwf)
at #P6i.#O6i.#M6i(DockHost #tm, Point #bVe, IHierarchyContainer #cwf)
at #P6i.#O6i.#N6i(DockHost #tm, Point #bVe)
at ActiproSoftware.Windows.Controls.Docking.Primitives.DockGuidePanel.HitTest(Point #bVe)
at ActiproSoftware.Windows.Controls.Docking.Logic.WindowDragProcessorBase.#caj(Point #daj)
at ActiproSoftware.Windows.Controls.Docking.Logic.WindowDragProcessorBase.#cNi(Point #bVe)
at ActiproSoftware.Windows.Controls.Docking.DockSite.NotifyWindowDragMove(Point location)
at #g7i.#B9i.#d8i(Object #xhb, EventArgs #yhb)
at System.EventHandler.Invoke(Object sender, EventArgs e)
at System.Windows.Window.OnLocationChanged(EventArgs e)
at System.Windows.Window.WmMoveChangedHelper()
at System.Windows.Window.WmMoveChanged()
at System.Windows.Window.WindowFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.PublicHooksFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)

 

I was able to reproduce this issue in the following way: 

- Open our app

- Open some tabbed documents

- Drag one out and make it floating

- Close our app

- Relaunch it and wait for components to load

- Our floating window appears, grab it and bring it to one of the docking zone

- The app will crash

 

Though I suspect this crash might be reproduced otherwise.

 

Thoughts?

[Modified 2 years ago]

Comments (24)

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

Hello,

Are you running our latest build?  We have a maintenance release almost ready to publish very soon and if this is a bug on our end, we definitely want to get it fixed before releasing that.  This isn't a scenario that has been reported yet and appears to be happening in our SearchHierarchyForDockTargetAtLocationRecursive method that walks down Docking-related containers to see if there is one under the passed location.  If so, it's transforming the Point from the ancestor DockHost down to the container that was found.  But in your scenario, that isn't working for some reason.

Can you please make a new simple sample project that shows it happening and email that with repro steps to our support address?  Then we can debug it to see what scenario causes this.  Please reference this thread in your email and rename the .zip file extension of what you send so it doesn't get spam blocked.  Thanks!


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

Seems the issue happens solely on Windows 10. If I delete our serialized layout file as if the application was just installed, the crash does not happen. After the first serialization (first time you close and reopen the app), the crash is always prone to happen when a dockable window is dragged to one of the docking spaces (up, down, right, left and center). This problem, however, does not happen on Windows 7. Out of curiosity though, I've taken the serialized layout file from our Windows 10 PC to a Windows 7 PC and the crash happened there as well. Very strange!

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

Hello,

It sounds like there could be something wrong with the deserialization process based on what you are describing.  We would like to help, especially since we have a maintenance release coming out in the next few days, but you need to send us a simple sample that shows it so we can debug with that per the instructions in our previous reply.  We'll watch for that.


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

I was unable to recreate the bug using a sample. I suspect this issue might have more to do with us and actipro itself.

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

Ok please let us know if you find out more detail about what is causing it.


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

After further testing, the crash happens only when a floating ToolWindow or Document is dragged over the ribbon, status bar or a docked actipro control. As soon as the cursor dragging the window enters the bounded area of the control, the crash happens. Knowing this and provided the above callstack, does this ring a bell to you? Looking at our internal reporting tool's crash screenshots, we also discovered that the crash also recently happened on Windows 7.

[Modified 2 years ago]

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

Based on the stack trace, it is where you are dragging around and there is logic that searches the control hierarchy of a DockHost to see what container is under it.  It then tests to see if the mouse location is over the bounds of that container.  Since the mouse location we pass in is DockHost-relative, we have to TransformToVisual that to the child container's coordinate system.  But for some reason, the setup in your scenario is saying that the container isn't within the DockHost's visual hierarchy.  I'm not sure how that scenario is happening and it doesn't make much sense, which is why we really need a simple.

If you are able to break into VS when this scenario happens, look at the IHierarchyContainer in our lowest-level stack.  Do a visual tree examination in VS and send us what it shows as the full ancestor hierarchy.  DockHost should be in there, but according to the stack, it's not.


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

Since I was having problems building your source code for WPF Studio 2016.1.633, I opened a support ticket but then I realized it might be best to continue our discussion here the ticket number is 34F-1FC09014-200B.

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

By the way, build 634 just came out today.


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

Here are two visual trees I captured for comparison:

Screenshots

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

Hi Alexandre,

Did you get build 634 (came out last week) to see if it's happening with that?  Unfortunately those screenshots don't really help since we don't know what container it is that has the problem of not being a descendant of a DockHost. 

What you need to do is break in VS when the exception occurs and in the Call Stack tool window, ensure you are on the lowest level "#P6i.#O6i.#M6i(DockHost #tm, Point #bVe, IHierarchyContainer #cwf)" (from your original stack trace).  Then go to the Locals tool window and you should hopefully see the parameters listed.  The last one is the container and is what we want.  In the Value column of the Locals tool window, it should have a magnifying lens button by it.  Click that and it will load up the WPF Visualizer for that element.  That's what we want the screenshot of.


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

Here you go:

 

Visualizer for faulty container

How it happens (When the window is dragged through the ribbon)

[Modified 2 years ago]

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

You never answered whether this still happens in our newest release from last week, which is build 634?  Please make sure to try that and let us know.

Also in your faulty container screenshot, are you sure you are at the lowest level in the call stack where the exception occurs, meaning the one that calls Visual.TransformToVisual?  Because in the first post's stack trace, you showed four nested calls of that, but your faulty container screenshot only shows you traversing into the first container.  So I suspect that one is not the lowest level level container if you have the same stack trace.  Please check that too and get us the lowest level container screenshot, along with a matching stack trace.  Thanks.


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

My bad, unfortunately v.634 hasn't fixed our problem.

The stack trace is the same as above and here are the 5 iterations of SearchHierarchyForDockTargetAtLocationRecursive

Visual hierarchy

[Modified 2 years ago]

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

Hi Alexandre,

Thanks, from the screenshot it looks like that last TabbedMdiContainer must be the culprit here.  It's likely referenced by the TabbedMdiHost or a SplitContainer within that but doesn't seem to be in the visual tree.  Can you do me one more favor and take visualizer screenshots like your did of that particular TabbedMdiContainer, but show me all the properties on the right and their values?  For instance I can only see through FlowDirection on the one you sent.  I'd like to see what all the other properties are set to. 

Also for the TabbedMdiHost that is the level above it in your last screenshot, can you expand out its children in the treeview, so we can see what it has there?  And if a child is a SplitContainer, please expand that out too until you get to TabbedMdiContainers.  Then take a screenshot of that tree.

Thanks, this information will help us build a code tweak for you to try.


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

The TabbedMdiHost doesn't seem to have a SplitContainer child. Here are all the properties of the TabbedMdiContainer:

TabbedMdiContainer details and TabbedMdiHost

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

Hi Alexandre,

Thank you for the updated info.  We are going to make some minor tweaks to try and catch this scenario.  Can you email our support address and reference this thread and we'll send you a preview build to try once it's ready?


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

Will do!

Posted 2 years ago by Alexandre Grégoire
Avatar

Thank you for the quick build!

Will this be included in v.635?

Oh and also, I've integrated your hotfix to our app and it did resolve the problem though I found that this change seems to mess with the floating window's ability to be selected upon deserialization.

 

Steps to reproduce:

1-Drag a window out of its docking space.

2-Close the app and serialize to a file.

3-Start the app once more and try to click on the title bar of said floating window. On our end, the window's border will become highlighted with blue but the title bar itself will not appear selected. What does it is either clicking inside the window or clicking either the maximize, minimize or the arrow submenu button.

[Modified 2 years ago]

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

Hello, yes it will be in the next build. 

Thanks for reporting the other issue.  We found the problem with that and it's resolved for the next build.  It was from a code change done for 634 to handle another problem but triggered this and is unrelated to the code change for this thread's crash report.


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

But your build was based on 633 wasn't it?

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

No, build 634 came out over a week ago and the preview build you received was based on that with additional updates.  We updated the same URL we sent you with a new preview build if you want to try the update for this particular fix and report back.


Actipro Software Support

Posted 2 years ago by Alexandre Grégoire
Avatar

Perfect thanks!

Posted 2 years ago by Alexandre Grégoire
Avatar

The issue with selection is indeed fixed.

The latest build of this product (v2018.1 build 0675) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.