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?

[jmoralesv]

Thanks for your answer @SeanFeldman, I will wait for your feedback and thoughts, before making any other changes in this form.

On the other hand, I would like to say that we can add the ability to enable word wrap in the message payload (in a similar fashion as the Autoindent checkbox in the right corner of the Message Text container in my first screenshot).

I'm a user of Service Explorer and I always have thought that having word wrap in text boxes that show message payloads would be a nice feature to have. But this is something we can track under another issue or PR 😃

[ErikMogensen]

Sean, could you make a drawing of what you propose? I assume you could move around things on a scrteen shot using a program such as Paint.

[jmoralesv]

Hello, is there any update for the question I posted in January?

I'm looking forward to hearing from you soon.

Thanks!

[ErikMogensen]

Sorry for the late reply, @jmoralesv. I think I understand what you suggest @SeanFeldman and I think it is an improvement. However, I think what is sizeable today should still be sizeable. Besides supporting existing behavior, there is #609 request font selection, which may require sizeable windows.

[jmoralesv]

Thanks for your reply @ErikMogensen. I will proceed then with the manual resize in the code for those two windows.

[jmoralesv]

Hi @SeanFeldman @ErikMogensen
I wanted to apologize for the long delay on this one as it took longer than expected to finish all the changes for supporting High DPI scaling in Service Bus Explorer, besides some personal and health issues that I was able to overcome last year.

You can take a look at the fork's history to see the changes: https://github.com/jmoralesv/ServiceBusExplorer/commits/main/?author=jmoralesv

As I'm planning on finishing some final tests this week on Windows 10 (I've been testing in Windows 11 for the last months), I wanted to know some things before opening a pull request:

• What other Windows OS do you think it would be worth testing?
• Is it ok to bring a PR for one commit (to squash all history)? I'm also thinking of rebasing my current fork on top of this repo's main branch, but I'll figure out if that is possible somehow.

Let me know if there is anything else I should be aware of before opening the PR this week.

Thanks!

[SeanFeldman]

There is no need to apologize, @jmoralesv. This is not a paid job, and help is very much appreciated.

What other Windows OS do you think it would be worth testing?

Windows 10/11 is excellent. You could give it a try on Windows Server 2022.

Is it ok to bring a PR for one commit (to squash all history)? I'm also thinking of rebasing my current fork on top of this repo's main branch, but I'll figure out if that is possible somehow.

Number of commits doesn't matter. We squash merge anyway. This is more for your convenience.

Let me know if there is anything else I should be aware of before opening the PR this week.

I encourage to open PRs while you're working and mark those as draft. This way you can have discussions on the code that's changing, Q&A w/o waiting till the end, etc.

[ErikMogensen]

@jmoralesv , I totally agree with what Sean wrote.

Looking at your branch, I see it's a lot of work and may become a great pain to get into the Main branch. To lessen the risk of other PRs causing issues I suggest you create a real PR for the forms and controls you are done with. No need to fix all of them before creating a real PR. That will also be a verification of what you have done so far.

[jmoralesv]

Hi @SeanFeldman @ErikMogensen
I've just opened a draft pull request, for a first set of changes, showing the initial support for high DPI in Service Bus Explorer: #797

These changes address the MainForm, as well as other forms and controls, but not all forms and controls, as those would make the PR bigger, which would be helpful when reviewing the code, as you mentioned in your comments before.

From my side, my concern would be that, if the PR gets merged, the updated forms would be fine, but users can complain about the rest of the forms, which would not be ideal, I guess.

Fortunately, I have all my original commits in a separate branch in my fork, so I can cherry pick any other change you might want to see applied from there 😄 that's the way I followed for this first PR by the way.

Please let me know how you want to proceed with this, thank you!

[SeanFeldman]

I vote in favour of several smaller PRs over one big PR. Don't think the rest of the team will object.

[jmoralesv]

@SeanFeldman thank you, good to know that so I can cherry pick my changes for the next PRs I will open, one after another 😄

[jmoralesv]

Hi @SeanFeldman @ErikMogensen I've just opened a second PR for your review: #800

Let me know what you think about it, thanks!