Hi, thanks for sharing these issues. I'll try to address them individually.



The Tests Window is mounted into Rider using a system called Wormhole, which is a JB component they are using internally for ReSharper. It work basically by streaming UI functions through a shared memory pipe, and is still under development.

Unfortunately the actual mounting of the window into the IDE and the tech that pulls it through the pipe is not under NCrunch control. This means that we don't have a way to solve issues related to the snapping of tool windows. It's my hope that issues like this will be solved by JB over time as they continue to work on Wormhole.



Are these issues related to the snapping of the window? I haven't seen them before and I'm wondering if you have a consistent way to reproduce them. There might be more I can do about them.



Right now RDI under Rider suffers from a range of issues that are interfering with the engine being able to pipe data into the UI. The good news is that I'm suffering with these problems too, and I've been working to fix them as I discover them. I have a number of fixes for this already pending in v5.16 and will push them when I've had a bit more time to test them myself.

RDI support was the last feature added to Rider in the 3-4 year development cycle, so it makes sense that it will have the most issues, since we had less time to dogfood and stabilise this area. Because it's also relying on piping the whole UI through shared memory, it's never going to be as responsive as what we have in VS ... but it IS supposed to work.



NCrunch's VS package has the benefit of 16 years of development, testing, Q&A, dogfooding, and all of that. We've only had support for Rider for a little over a year, and it's still in beta. Rider is much more challenging to support because the native IDE is JVM based, so we don't have an easy way to share code between the engine and the IDE.

I don't expect that it will be possible to get Rider's plugin as fast or as reliable as the VS one, but we're more or less at parity in terms of features... now it's just getting the stability worked out.

I've had a go at reproducing this on my own machine (I use NVIDIA Surround too), but it doesn't seem to happen on my end. Probably there is an environment component to the problem. You've mentioned that this seems to affect other non-NCrunch tool windows in Rider too? Do the effects seem to be similar?

If you resize the tool window, or close and reopen it, does it fix the problem? In theory this should trigger a refresh.

Unfortunately rendering our tool window in the same manner as a code window isn't an available option, as this won't enable the wormhole functionality we need to pipe the UI between processes.

My options in solving these issues are quite limited. My best hope is that if I can identify when the issues appear, I can force the system to just do a full refresh of the window to try and clear it.

It does not seem to affect any other windows.

Resizing, closing and opening does not solve the problem, only restarting Rider.

I installed 5.16.0.2 today, and the same issues occurred after having the screens turned off for a while, and then turning them on again. RDI overlay seems to never work when this occurs. I'll keep an eye out for miss-aligned RDI overlays, I haven't seen that today.

Another observation that may or may not be related. I have three screens, and sometimes after turning them off and turning them on, some windows sometimes changed size, specifically if I left them in full screen mode (on one screen). I'm gonna experiment a bit with that, see if these issues occur if I don't leave any Rider windows in full screen mode.

Also when ever minimizing any of the NCrunch windows, it briefly moves to the upper left corner of the surround display (my left screen), only for a fraction of a second, but enough to notice, before it is gone.

A variant of the above occurred today, where the scrollbar is there, it's just incorrectly offset (I guess the trace output window is). It's offset both vertically and horizontally, and resizing the NCrunch Test window also resizes the Trace Output window, but it's always out of boundaries with the main window. Maybe the window size information used to draw the Trace output window is incorrect sometimes somehow? Is it suppose to re-render/redefine it's boundaries if the window is closed/hidden and opened again?

https://drive.google.com..._AzNZV/view?usp=sharing

EDIT: I realized that as soon as I click on any of the other panes and back again to Trace Output, the trace output window have re-rendered as described before; no scrollbar.

Thanks, I'll keep posting new findings in hope something comes to mind :)

I tried turning surround off (still multi-display), the same problems still occur.

Regarding window snapping, I realized I've been using "Float" as View Mode for the NCrunch Test window, when switching to "Window", snapping works just fine! Can't believe I missed that :) Doesn't solve the scrollbar / content alignment issues with the Trace Output window though.