Crash when docking

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!

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!

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.

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

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

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.

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.

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.

By the way, build 634 just came out today.

Here are two visual trees I captured for comparison:

Screenshots

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.

Here you go:

Visualizer for faulty container

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

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.

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

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.

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

TabbedMdiContainer details and TabbedMdiHost

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?

Will do!

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.

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.

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

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.

Perfect thanks!

The issue with selection is indeed fixed.