Support High DPI Scaling

[beaubgosse]

Seems like the app doesn't scale properly and has somewhat blurry text when scaled for high DPI screens.

Is this something anyone has looked at before? I tried fixing the issue following these steps and it mostly worked:
https://docs.microsoft.com/en-us/dotnet/framework/winforms/high-dpi-support-in-windows-forms

But that would require upgrading to .Net 4.7; is that something we could do?

Also, even following those steps, there are still a lot of graphical bug to fix. It seems like this post has a lot of good things to look for. https://stackoverflow.com/questions/22735174/how-to-write-winforms-code-that-auto-scales-to-system-font-and-dpi-settings

Without proper Scaling today (On a 4k Monitor in Windows 10 scaled to 150%):

With proper scaling (On a 4k Monitor in Windows 10 scaled to 150%):

[ErikMogensen]

Oh, I hadn't noticed. Perhaps the PR #362 will help? Please take a look at it.

[beaubgosse]

Cool. I think that PR fixes the issue at least from my initial testing. I'll reply in that PR. Or do we want that PR to reference this issue? I've updated this issue with before an after pictures of the scaling problem. @ErikMogensen

[ErikMogensen]

Let that PR reference this issue if you have tested it and it makes it better.

[beaubgosse]

Let me put in a real connection string and test all the different views. Also it might be nice if someone on Windows 7 tested this since scaling support is different.

[paolosalvatori]

Thanks @ErikMogensen and @beaubgosse and sorry for coming late to the conversation :) Can I close the issue?

[ErikMogensen]

No, as @beaubgosse writes in PR #362 it is not fixed. We need someone with a 4K monitor and knowledgeable in WinForms to fix this.

[paolosalvatori]

Feel free to reopen the issue, for the moment I will close it.

[jmoralesv]

Hi all,
I was looking for high DPI support in Service Bus Explorer because I have new 4K monitors, and I came across this issue. I wonder if there are plans to add this. If not, I was thinking on helping to add this, I have some Windows Forms background from some years ago (I'm not an expert but I can do some things 😄)

I may take this as a start: #362

[SeanFeldman]

@jmoralesv that'd be great. Thank you 🙂

[jmoralesv]

Hello @SeanFeldman
I've been making progress on this issue by updating most of the forms and controls to support high DPI screens, as you can see from my fork, however I have a question regarding the Repair and Resubmit Message window (MessageForm in the solution).

In this form I found two SplitContainer controls:

• One horizontal allows the user to modify the size of the two containers at the left (Message Text and Message Custom Properties)
  

• Another one that allows the same thing between the Message Properties container on the right and the other two containers on the left.
  

My question is if these two SplitContainer controls are still needed, because their presence complicates how the child controls inside of the three said containers are rendered in a high DPI screen. If those SplitContainers can be removed, it would be helpful, so I can introduce a TableLayoutContainer which can handle the resizing of the child controls automatically. However, the user won't be able to resize manually the three containers.

The same question applies to the Message tab, when seeing the messages in a topic for example:

If the SplitContainers must be preserved so users can keep using this feature, I can fallback to manual resize calculation, it's not desirable but doable.

Thanks for your help with this.

[SeanFeldman]

Good UX question. I might be a little subjective but let me lay out the rationale for the three parts and how those are usually used.

The message payload is usually where the focus is primarily in the context of a single message. For a list of messages, it's the standard information such as message ID, sequence number, size label and enqueued with expiration times. Having that as a split container position in the left-top section makes sense. If looking at the list of messages, the 2nd split container is needed to see the payload. Bu the context of a single message, it's used to show custom properties (user properties or custom headers).

It would be OK to show custom properties/headers on the right side, but the need to show the type (which is not needed for the application/system properties/headers) requires more horizontal real estate.

I wonder if for the list view, we could move the message payload to the right and make the two columns equal in size. The listing of message would still be enough to show all the info associated with each message w/o the need to resize the column. While the right side column would have (in this order) message payload, system properties, and custom properties. If the right side column is enough to show the payload, most likely, it would be enough for both types of properties.

@paolosalvatori and @ErikMogensen, would you agree to that and do you have any suggestions and ideas to help @jmoralesv?