I cannot get WinForms to properly scale the UI when the DPI setting is changed: different controls are scaled by a different factor, messing up the UI design.
This is what I’ve tried:
In Windows 7 set the text size to 100% (= 96 dpi).
Start Visual Studio 16.9.1 and create a new WinForms app with C# and .NET 5.0
Add a simple text box and a button to the form
Compile the project
Run the program: both controls have a height of 23 pixels (checked visually and programmatically)
Set the OS text size to 150% (= 144 dpi) and log out and in again to apply the changes
Run the program again: now the text box has a height of 31 pixels and the button has a height of 38 pixels.
So when increasing the OS text size (= DPI) by 50%:
the height of the text box increases by 33%
the height of the button increases by 67%
Notes:
I checked all guidelines described here: How to write WinForms code that auto-scales to system font and dpi settings?. The application is DPI-aware and AutoScaleMore and AutoScaleDimensions are set correctly (default values in .NET 5.0).
I also tried this with .NET 4.7.2 and Windowds 10, but the two controls always scaled differently.
Why are these controls scaled differently?
Why are they not scaled by 50% as you would expect?
What can I do to have these two controls scaled by the same factor?
I have created a document in an open office with a multi-line form field:
The issue I am having is when the dynamic content exceeds the initial size of the multi-line text box:
Sure I can re-size the Text Box in the original template but the dynamic content may be from 1 to 50 lines and I want the text after the Text Box to be close to the last line of dynamic content.
Can someone suggest a way to solve this?
I have once coded a solution to set the width and height of a textbox programmatically based on the characters supplied. I think this was a school assignment a long time ago.
This can be done with both VBA in a code behind or probably with a macro even. Or with VB.net.
I don't have the code I used way back when, but basically determine the maximum width you are able to provide in character width, the preferred width. Determine the pixel requirement per character for that width. This becomes the textbox width.
Divide your total string character count by your preferred width character count. Round up, calculate the pixel height per character. And use this value times the rounded result for the textbox height. Dirty but it should work.
Any chance you can change to a label and set AutoSize to True? You can fix the width and let the height auto adjust. This should be done before converting to a pdf. In fact all of the sizing should be resovled before pdf conversion.
Another Down voter without a comment, should not be allowed.
I created an extended RichTextBox with better image displaying support. For short: I parse text-based image placeholders from the RTF-input, replace them by an empty paragraph with a propriate spacing (image height) and draw the images in the paint event above the text (inside the spaces).
The problem now is that the spacing seems to be wrong. I calculated the twips with the following formula:
size.Width = (int)((1440 * size.Width) / graphics.DpiX);
size.Height = (int)((1440 * size.Height) / graphics.DpiY);
Where graphics is from my RichTextBox and size is the image size. As the DPI value is 96, it is basically twips = 15 * pixels.
I tried the RTF control words \sbN and \saN with my calculated twips-value (I controlled it with the debugger, the value is as expected). I also used interop with PFM_SPACEBEFORE and PFM_SPACEAFTER.
Both ways give the same result. The problem is that the real space inside the RichTextBox is too big. If I multiply the calculated twips value with 0.75 it fits. But I really don't get why this happens.
My first thought was the factor 72 / 96 (PPI / DPI) which is 0.75. But this makes no sense for me.
The additional space increases proportional to the image height. So the space is barely noteable for small icons (e.g. 24 pixels height). But for larger images (e.g. 320 pixels height) the additional space is huge.
Some ideas? Is this a bug in the RichTextBox control?
To clarify: I used System.Windows.Forms.RichTextBox as a base class.
Ok I found the error by myself. I had to use the DPI values of the image instead of the DPI values of the control. The image DPI values were 120 so the factor was 0.8 (not 0.75). Now it fits. I leave the question here in case someone has the same problem.
If I create picturebox element on a form, the properties panel allows me to set the width/height to a value representing pixels.
However in code it seems a different unit size is used for measurement.
Example; i put the width at 128.
Both in the editor and in runtime the form will show a picturebox of 128 pixel width.
Now, If i try to read picturebox.width value in code it gives back 85.
If I try to change the width to 128 in code, it gives me an actual bigger box then 128 pixels.
What am I missing here?
I am developing a map control in WPF with C#. I am using a canvas control e.g. 400 x 200 which is assigned a map area of e.g. 2,000m x 1,000m.
The scale of the map would be: canvas_size_in_meters / real_size_in_meters.
I want to find the canvas_size_in_meters.
The canvas.ActualWidth gives the Width in DIU's (Device Independant Units). So, 400 DIU's is 400/96 = 4,17 inches, PROVIDED that the physical resolution of my monitor is 96 dpi.
However, using a ruler, I found that the physical resolution of my monitor is 87 dpi. (There are only few monitors that ACTUALLY have 96 physical dpi)
That DPI difference (10%) translates to a +10% difference in the actual map control width on screen.
How do I measure the size of a WPF control in inches EXACTLY and regardless of screen resolution and DPI setting ?
How do I measure the size of a WPF control in inches EXACTLY and regardless of screen resolution and DPI setting ?
This isn't actually possible, because for it to work, WPF would have to know the resolution (in terms of DPI) of your monitor. Sounds nice in theory, but in practice windows doesn't know this information. This is why windows itself always assumes 96dpi blindly instead of being smarter about it.
Even if there were some way to manually tell it, or if your particular monitor has a custom driver that does pass the correct information to windows, this isn't going to work on anyone else's computer, so windows doesn't pass this information on to any applications.
The best you can do is draw a scale like google maps does. You know that 1 pixel == 1 mile, so you can draw a 50 pixel line on your map, with a label saying "this line equals 50 miles"
There is way to compute current pixel size in mm or inches. As mentioned in the earlier posts, it is not a fixed value and would vary depending on the current resolution and monitor size.
First get the current resolution. Assume it is 1280x1024
Now get the monitor width in mm using GetDeviceCaps function. Its a standard windows library function.
int widthmm = GetDeviceCaps(deviceContext, HORZSIZE);
My monitor width is 362mm
So pixel size = 362/1280 = 0.282 mm
The accuracy of this method depends on the assumption that the display area covers the width of the monitor exactly.
So to answer the original question, the canvas size of 400 x 200 pixels would be
(400 * 0.282/1000) x (200 * 0.282/1000) in meters when shown on my monitor.
Thank you for you prompt reply.
I totally agree, but I didn't want to believe it in the first place. You see, there has to be an approximate calculation of the scale of the map if the map is used to display different layers of map data (scale dependant).
Most applications use a slider control with e.g. 10 discrete map levels to set the "scale".
Having an absolute scale is not crucial for the application, it would be nice to display an indicative scale, like 1:15,000.
An absolute scale would require for an extra variable monitorPhysicalDPI (initially set to 96) that if the uses chooses to change would give slightly better scaling (again it's not crucial). The size of the map control would be:
map.ActualWidth * (96/monitorPhysicalDPI) * inchesPerDIU, inchesPerDIU is 1/96
Again these are cosmetics.. Wouldn't it be nice if Windows knew the ACTUAL control's dimensions? (user would have to give information about the screen dimensions on OS setup, or simply installing the monitor INF file)