Hello,
I assume you have UseHostedPopups="False" set.
While we fully test our WPF controls in WPF-based applications, we don't normally test them in various interop scenarios like in MFC apps. If you'd like us to take a look, please make a new simple sample project that shows it happening and send that to our support address. Reference this thread in your email and be sure to exclude the bin/obj folders so it doesn't get spam blocked.
When live splitting is off and not using hosted popups, we internally create an adornment WPF Window to host things like splitters. We get the target WPF element and call PointToScreen to get screen coordinates of it. Then we position the host Window over the screen bounds. From what you are describing, it sounds like something with that bounds-determination logic isn't working properly.
If it's due to PointToScreen not returning correct results, then there wouldn't be much we could do since it's a core Microsoft API. Or are you thinking the offset of the adorner is the same amount from your MFC window's client bounds top-left down to the top-left corner of the root WPF control in your app?
What you described in the followup would make sense since when UseHostedPopups="True", the slider, dock guides, etc. are rendered in the same WPF Window as the DockSite. But if you have interop controls in that Window, you run into the annoying "airspace" issue in WPF where interop content always renders on top of WPF content.
Since the problem only happens with UseHostedPopups="False", it must be due to something throwing off the positioning of the adornment WPF Window we create to host things like splitters, specifically to work around WPF's airspace issue. That transparent adornment WPF Window is separate from the main application WPF Window, and that's where a positioning issue must be occurring.
