Cursor Size on High Resolution Displays (Win 10)

[mje]

TL;DR: Is there a way to fix the small cursors in LabVIEW on Windows 10 while working with desktops scaled beyond 100%?

Now that I routinely work on 4k displays, the legacy IDE and applications created from it are becoming a bit hard to use. The non-system cursors LabVIEW use are too small-- they don't scale like the rest of the user interface on Windows 10, inclusive of the system provided cursors:

That cross on the diagram is smaller than one of the tunnels. To add insult to injury, when I capture a screenshot with the cursor it miraculously scales in the image, so I'm thinking this is something LabVIEW is doing with it's cursors that prevent the OS from resizing them (the rest of the IDE scales beautifully with the build in Windows scaling). Also why I'm posting an image of my screen (don't tell anyone).

I can work around this by having the OS to flash the cursor position when I lose it. Which happens a lot. But I am worried about complaints that may creep up from users of our applications because the non-system cursors on front panels are similarly unscaled. Is there a way to fix this?

I'll preemptively say NG isn't an option, there are reasons I'm still working in LabVIEW 2017.

[hooovahh]

That is seriously small and would be very annoying.  Hope you have custom DPI settings for your mouse.

[LogMAN]

There is actually an idea on the Idea Exchange for this and it was rejected for already been implemented!

1 hour ago, mje said:

I'll preemptively say NG isn't an option, there are reasons I'm still working in LabVIEW 2017.

You probably won't like their solution...

Here you go: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LabVIEW-DPI-aware-to-support-high-DPI-screens-and-Windows/idc-p/3672540/highlight/true#M37286

[mje]

Yeah, I saw that idea exchange entry. It broadly falls under the same issue, but this is a bit more specific. I'm fine with the blurriness that can result from the OS scaling the native display, that's expected when there's not an integer multiplier mapping between the scales. At 200% my display isn't blurry, it's just more pixelated, but a fractional scale of 150% or the like will produce those effects which I wouldn't classify as a defect. However there's something special about the mouse cursor-- while the rest of the interface is scaled by the OS as expected, the custom LabVIEW cursors are not thus adversely affecting usability.

However they can be scaled. Take for example this screenshot of the same bit of code taken via the Windows Step Recorder:

Somehow there's an auto-magical cursor scaling in the image that doesn't appear on screen. Shenanigans I tell you.

As for DPI, Windows handles that quite elegantly. There's a seamless transition between modern applications and those which the OS is treating as legacy, no fiddling of mouse settings are required. Windows 10 is very impressive for this and is one of the reasons we only plan on supporting high resolutions for our LabVIEW applications under Windows 10.

[ensegre]

Oh that's not all. There is also this idea, where AQ said that he will try to rattle the cages, and this thread. On linux it is worse, but run_scaled may be viable.

[LogMAN]

1 hour ago, mje said:

Somehow there's an auto-magical cursor scaling in the image that doesn't appear on screen.

A screenshot consists of two elements: A picture of your block diagram and a separate picture of the mouse cursor at that moment. The software also reads the position of the cursor and puts it back on top of the block diagram, scaling it to the current cursor size (of Windows that is) in the process. This is why it looks bigger in the screenshot that it does on your monitor.

That being said, if NI isn't willing to implement high DPI cursors in LV "classic", maybe there is a way to add or replace the cursors using one of the resource editors.

[ThomasGutzler]

I understand this can be an issue for users and I have something to add: The select tool on a graph/chart turns into tiny black cross-hairs impossible to locate on black background. Terrible!

But as a developer, I wonder how you deal with the fact that you have to have the help window and the probe window on the same screen as your BD for the scroll down menus, context menus and mouse-hover displays (during debugging) to work. It drives me crazy. Although, this might only be an issue when you work with two screens and they run on different zoom levels.

Edited March 14, 2018 by ThomasGutzler

[JKSH]

5 hours ago, ThomasGutzler said:

this might only be an issue when you work with two screens and they run on different zoom levels.

That's correct.

That also means it is an issue for me, as I have 2 screens with different scalings.