Thanks for reporting this issue Symphara.  

LogViewPlus does not automatically adjust DPI settings if they are modified.  Is the problem resolved on an application restart?  I will investigate this issue to see if I can recreate it.

We've put a lot of work into the custom log format detection - thanks for noticing!  :-)

Toby

Thank you for replying so quickly. The DPI settings are not modified!

The application simply has the wrong DPI scaling when used over Remote Desktop Connection.

So basically from any high-DPI computer try to connect using Remote Desktop Connection to another computer, while keeping the Display Configuration to "Large" (full screen). Then run LogViewPlus on the remote machine. It's not scaled correctly.

Restarting the application or restarting the remote connection (while leaving the application running) has no effect.

Thanks for the update.

I have been able to recreate the issue.  The problem seems to be an issue with how Windows and RDP handle scaling of Winforms applications.  I am able to partially resolve the problem by turning off "Fix scaling for apps" in the advanced scaling settings of the remote machine.

Unfortunately this setting is global and might impact other applications.  I have researched alternative solutions but because the underlying issue is settings related I cannot see any other alternatives except disabling DPI scaling when an RDP connection is detected.  This should force the controls to be appropriately sized, but will likely result in slightly blurry text.  I will look into adding a configuration setting to disable DPI scaling in the next release.

Hope that helps,

Toby

We have updated the latest version (v2.6) of LogViewPlus to include a new command line option.  You can now start LogViewPlus from the command line with:

logviewplus.exe -DisableScaling

This will disable DPI scaling in LogViewPlus and leave the scaling to Windows.  Windows default scaling ensures controls are adequately sized, but may result in slightly blurry text.  Note that command line arguments can also be specified by modifying Windows shortcuts.

For now, the two options of running LogViewPlus without scaling or turning off "Fix scaling" in Windows are the only two workarounds we are going to be able to provide for running LogViewPlus in RDP at high DPI.  Neither of these solutions are ideal.  I have made a note to investigate this issue further in a future release.

Hope that helps.  Thanks again for reporting this issue,

Toby

Hi Toby,
I've got another bug to toss on your todo list. I will try out the logviewplus.exe -DisableScaling Setting, but I wanted to show off a similar-ish bug. I have a 2k display, and my coworker has a 4k display, and we've occasionally noticed logs that are inconsistently scaled. Some lines seem to have the correct scaling modifier turned on, some don't. For me it's fine because I have a 27inch screen, and so I have loads of real estate. But my coworker has a 17inch 4k screen and so the text (even at 16pt font) is mostly tiny in the logs themselves. The rest of the UI is fine. (This screenshot is from her screen) (sorry I had to blur it a bit to protect user privacy, but hopefully you can see some lines are different sizes from others)

I'm attaching the screenshot and dxdiag logs if you can use them.  Again, we'll try out the disable scaling setting and see if it helps, but to me this was a pretty clear signal there's a bug where certain log line entries are being treated differently from others. Hopefully that makes tracking down the issue easier!

HI Memnarch,

Thanks for reporting this issue.  That is a very strange bug indeed.  Are these log lines permanently scaled incorrectly?  What happens if you scroll or refresh the log file?  I have seen behavior somewhat similar to this if the screen scaling is changed and the application is not restarted.

There is a known issue in 2.6 with drawing multiple highlights in the grid which will be fixed in the next release.  I can see that the log line selected has multiple highlights.  This could be contributing the the problem as well.  (For performance, grid lines with multiple highlights are drawn completely differently from grid lines with a single highlight).

I will take a look at the sample log file and see if I can recreate.

Thanks again,

Toby

Hi,
Got it. I am not certain if I had highlights in here but I think you might be right. I did not include a sample log because it's from a user's machine, so I can't share for privacy reasons, sorry. But interesting to know that we might see a fix in the next release anyway, thanks!

In this case, I mean the words highlighted in yellow rather than the 'highlights' feature.  From the screenshot you provided, I can see two words highlighted on the selected line in the log entry display on the bottom of the screenshot.  Neither of these words are highlighted in the grid.

I have contacted the third-party grid developer about the highlight issue.  They have provided a new method for drawing these rows which has already been implemented in the next release.  Hopefully, this change will also resolve the DPI issue.

I will post back here when we have a BETA release available which is currently about 4 - 6 weeks away.

The issue with highlights is a regression.  You can try installing a previous version to see if that helps.  Unfortunately, I am not 100% sure when the issue was introduced, but I suspect the previous version (2.5.51) will be fine.

Hope that helps,

Toby

I bought a license for the application and updated it to 2.6. On the positive side, the -DisableScaling does work on Remote Desktop and it's usable, if not ideal.

On the down side, the application no longer works correctly for me on the local (hi-DPI) screen. It did work when I posted my first message, I just had a problem through Remote Desktop back then. Now the local scaling is off too, fonts are way too small. Of course using -DisableScaling fixes this but it does introduce some blur.

As a completely unrelated issue, my log files are UTF8. Initially I noticed that it didn't display correctly international characters and I set the encoding to UTF-8 in Settings. This caused the application to conspicuously reload the log, but it still didn't display international characters correctly. I completely restarted it and then it worked fine, however this is probably not what was intended.

Hi Symphara,

Thanks for reporting the UTF-8 issue.  The restart should not be required, so this is something we will need to investigate.

Sorry to hear you are having problems when running high DPI locally.  This surprises me because the 2.6 release did not make many DPI specific changes.  I just ran the application on a high DPI display on a mixed DPI desktop and could not see any obvious issues.

There is one change we made regarding painting the application via DirectX.  This change was not made for DPI reasons, but it might be causing the problem.  You can effectively revert this change by running LogViewPlus with the -DirectX option.  Can you please see if this helps with your issue?  I am unable to recreate locally.

Hope that helps,

Toby