Why the custom task pane height is set in points?
What do points mean? If I want to set the custom pane height to work with all the display resolutions, how do I need to set this? using some kind of formula? For example I set as below in a screen resolution of 3024x1890 and it is shown correctly:
ctp.Height = 160;
However when I visualize it in a screen resolution of 1920x1080 the custom task pane is not shown correctly, I mean, height is bigger that the one in 3024x1890.
Pixels and points are static measurements - they don't change based on other factors: 1 pixel is always 1 pixel and is the smallest piece of a screen that can display colors. 1 point is always 1 point and is an abstract unit, only having meaning when referenced in relation to other points.
You need to set up the AutoScaleMode of the UserForm to the Dpi which specifies the different types of automatic scaling modes supported by Windows Forms. Then you can try to use dock and anchor properties to auto resize and adjust controls. That may work only for standalone applications and not in Outlook (depends on Outlook version). So, additionally you need to detect the DPI level and set up the UI accordingly.
Take a look at the following pages for more information about scaling in Windows:
Windows Forms DPI scaling
Creating a DPI-Aware Application
Automatic scaling in Windows Forms
Related
I have an VSTO Outlook Add-in which shows a custom task pane (ctp). This ctp embeds a usercontrol which in turn contains an elementhost. The elementhost hosts an WPF user control.
At Add-in startup I create the ctp and I set it a fixed height, e.g. 120 points. I have noticed that depending on the screen resolution the ctp height gets smaller or bigger.
So I would like to know if there is a way to set the ctp height according to the current screen resolution so it does not get smaller or bigger.
For example some formula:
ctp.Height = Default_Height * Y_Scaling_Factor
I have tried setting the autoscalemode to font and dpi and it does not work.
You need to set the AutoScaleMode property to None if you don't want to get the container scaled according to the screen resolution.
The AutoScaleMode property specifies the current automatic scaling mode of this control. Scaling by Font is useful if you want to have a control or form stretch or shrink according to the size of the fonts in the operating system, and should be used when the absolute size of the control or form does not matter. Scaling by Dpi is useful when you want to size a control or form relative to the screen. For example, you may want to use dots per inch (DPI) scaling on a control displaying a chart or other graphic so that it always occupies a certain percentage of the screen.
For more information about automatic scaling, see Automatic Scaling in Windows Forms.
Also you may take a look at the AutoSize and AutoSizeMode properties that resize the form according to the setting of AutoSizeMode.
I've been updating an existing Win32 app to be DPI aware. Following various guides on MSDN and other sites, I manually scale my coordinates and font sizes according to the current monitor DPI.
I just stumbled upon this message: CCM_DPISCALE. The docs say:
Enables automatic high dots per inch (dpi) scaling in Tree-View
controls, List-View controls, ComboBoxEx controls, Header controls,
Buttons, Toolbar controls, Animation controls, and Image Lists
But what does it actually do? I try sending the message to my control like so:
SendMessage(hWnd, CCM_DPISCALE, (WPARAM) TRUE, 0);
But it has no discernible effect on font, size, layout - anything, at any DPI.
I am using Comclt32.dll version 6.0, as per the documentation.
The only reference I can find to this message when Googling it is that MSDN page, and a link from the LVCOLUMNA documentation.
What is this message actually supposed to do?
I figured out at least a small part of what this does.
In a ListView control, if columns are created with fixed width (LVCFMT_FIXED_WIDTH) and as long as you don't specify LVCFMT_NO_DPI_SCALE, CCM_DPISCALE will scale the column width according to the current DPI.
If you have a grouped LVS_REPORT style ListView, and the group header contains an image (LVGF_TITLEIMAGE) that image will also be scaled (but not the group text (LVGF_HEADER))
I didn't test if this scaling is per monitor or not, and I didn't find anything else that this message does (although as per my question, it is documented to effect multiple controls). I am interested in finding out what else this message does!
I'm trying to emulate Xcode's toolbar controls to show/hide the Navigator and Inspector:
...but without the bottom pane (only left and right: two segments)
I screen-captured the icons from Xcode's UI and traced them in an image editing application. The resources for the left pane are:
#1x:
(20x20 #72 dpi)
#2x:
(40x40 #72 dpi, although using 20x20 #144 dpi seems to make no difference)
The right-pane counterparts are identical, but flipped horizontally.
All rhe resources are stored in the asset catalogue, as follows:
I dropped a segmented control on the toolbar, to create a toolbar item with a segmented control inside it, and set the image attribute for each segment (0 and 1).
Image Scaling for both segments is set to "Proportionally Down". The segment control has segment width "Fixed" checked, with a width of 48 for both segments. The toolbar item has Minimum Size of (83 x 25) and Maximum Size of (100 x 28).
The icons display correctly on the storyboard (Interface Builder).
However, when I run the app, I can not get the icon images to display appropriately.
If I launch my app on a retina monitor, no icon is displayed on either segment.
If I move the window to the external, non-retina monitor, both icons are displayed.
If I remove the one of the two image sets from thew catalogue and run the app, the other icon is correctly displayed! (on either monitor)
If I further set the same, remaining image for both segments, they display correctly!
If I leave both image sets in the project, but reset the Image field in one of the segments to empty, the other icon isn't displayed eihter!
What on Earth is going on??
I have put a sample project on GitHub that reproduces the issue.
Edit: Just to make sure, I extracted the resources from the compiled app binary using the cartool command line utility (as explained in this answer), and all 4 images are there at the right sizes...
Solution: As suggested by Ivan's answer below, I switched to using vector graphics (PDF) for the icons. I downloaded the trial version of Acorn and recreated my icons at 1x size, then exported as PDF.
To avoid blurring at the scaled up size of #2x at runtime, I had to make sure all coordinates in the editor were integers, and also check the box for "Snap to pixels" in the Vector Shapes inspector for each shape layer:
(Happy Ending)
$ git commit -m "Fix toolbar icons for good (PDF)"
According to my experience, using of bitmaps in toolbar is troublesome. You can try to target exactly recommended resolutions to possibly avoid some problems: https://developer.apple.com/macos/human-interface-guidelines/icons-and-images/custom-icons/
However, the cleanest way would be to use vector (pdf) icons, as they simply work as intended.
I would like to change the screen size of the ARC-Welder chrome-extention to a 7inch screen - displayed on my pc - to test an app on different screen sizes.
Can this be done using for example the meta-data input?
Similar to a question that I asked recently but I think shares the same answer. It seems that there are few choices when it comes to form factor, and based on the answer to my question I think that you can only use the three form factor presets for now.
(from #Elijah Taylor)
The size of the window is not configurable per activity*, but the orientation is. The two options in ARC Welder that control the window are:
Orientation: This is either landscape or portrait, which will be the default orientation for your app. However, if you set a screenOrientation on your Android activity, this can override the orientation per activity, with the window rotating to compensate. There is a performance cost to rotating this way because the plugin will be rotated via CSS.
Form Factor: This is one of phone, tablet, or maximized. This controls the overall size of your app globally.
but for Chrome 42 and up you can use the metadata {"resize": "reconfigure"} to allow arbitrary user resizing. Your app must be able to relayout with a variety of aspect ratios and resolutions in this mode.
My question at:Android ARC app for chrome, set size of windows for different Activities/Layouts
You can Use this MetaData :
{
"resize":"reconfigure"
}
just thought i'd mention that there is also "formFactor": "fullscreen" if want to test full screen it also works with "resize":"reconfigure"
I am having a property sheet and added three pages.In the first page I added a picture control and in the properties of that picture control for "Image" property I am setting a bitmap.And was able to load very successfully.But,the problem here I faced when I run my exe then I am getting bitmap on the page header(which is some kind of banner for the page.)But what I noticed is there is some gap between the banner bitmap and the frame edge (which is occurring at the right top corner). And when I ran my xxx.exe on a Japanese machine then I had observed like the sheet is somewhat stretched and banner bitmap is not stretched completely till the edge of the sheet (top right corner)for Instance if we take a dialog on load a bitmap on it then we can observe that it is entirely got stretched till the edge.
So how can we avoid this issue like whatever the operating system it is and whatever the resolution it might be that banner should get stretched till the edge of the sheet.The gap has to be removed.
I am not loading the bitmap dynamically (setting in the properties.)
Can anyone please help me ti achieve this
The reason you get different results on different systems is that dialogs and controls are sized using "dialog units" which are based on the average size of the font, rather than an absolute number of pixels.
By default a static image control will resize itself to the size of the bitmap it's displaying. So if the dialog itself ends up bigger than normal (because the font is physically bigger), the picture control will appear to have shrunk, leaving a gap.
You could try setting the SS_REALSIZECONTROL style on the static control. The normal behavior of the static control (when displaying a picture) is to resize itself to the size of the bitmap, however the SS_REALSIZECONTROL style overrides that behavior and instead causes the bitmap to be resized to the size of the control. However the results of that may be less than optimal (e.g. the aspect ratio will probably be wrong), so instead you may want to look into scaling the bitmap yourself.