How to Adjust GUI on Different Screen Resolution ?

[umer_awan]

Hello All,

I have an application that is to be deployed on different stations having different screen resolutions. I want my application to be responsive i.e. it should be adjusted perfecty well according to the resolution just like responsive website. Is there any way of doing this?

[RobertoBozzolo · Accepted solution]

You have at least two easy ways to accomplish what you want: resolution adjustment and splitters.

The former automatically scales panel when it is displayed on a screen with different resolution than the one it was desigend on

Splitters need a bit more effort: basically they can be used to modify the aspect of the window when they are moved interactively by the operator or programmatically with OperateSplitter. You can decide which controls are adapted when a splitter ir operated on and whether they are moved or resized.

In case of your sample UI, a horizontal splitter could be used to resize the textbox and move the buttons down when the panel is maximized.

The choice between these solutions it's on your hand: I personally don't feel good with the brute scaling operated when using resolution adjustment so I normall use splitters to adapt application windows to the screen size.

You can see examples of splitters in docking.prj and splitter.prj examples located in samples\userit folder. To have an example of the first methos, simply set resolution adjustment attribute to 100, change the screen resolution and see what happens when you launch the program.

[umer_awan]

Thanks alot

Jan

[Ian.W]

This issue is in my backlog too.  It is a tricky area, and I'm hoping any others with succesful strategies can chime it.

Today more PCs have high-dpi displays (e.g. Surface Pro 3 with 3200x2000). Just using splitters falls short here because the fonts on your UI will remain tiny. Resolution adjustment can help, but then you'll likely want to constrain the aspect ratio of the window to avoid squished/stretched fonts. And with screens of different aspect ratios, my thinking is that a combination of both methods is needed.

I'm thinking I'll try to implement a system where the overall size of the UI can be increased with a control, and that will programmatically activate resolution adjustment, then apply a constant aspect ratio increase, then deactivate resolution adjustment, and resume splitter-based resizing. 

I'd love to hear if anyone has gone down this path already!

--Ian

[layosh.b]

There is a hard way to do that right.
Build the user interface programatically, provide different uir for each resolution.

[ElectroLund]

---

@layosh.b wrote:
There is a hard way to do that right.
Build the user interface programatically, provide different uir for each resolution.

---

Whoa, that's hardcore.

I am seeing another poor side effect of using the scaling attribute on my panel.  After maximizing, resizing multiple times, the controls on my panel seem to be "wandering" and the fonts in the menus and controls are getting weird. 

[LuisG]

The problem of "wandering" controls and fonts can happen when each scaling operation takes place relative to the previous layout, rather than having each scaling operation take place relative to the original layout on the panel. When that happens, all the cumulative rounding that necessarily needs to take place, as each part of every control is scaled proportionally, result in the drift that you're noticing (especially as far as fonts are concerned, and also controls that have a fixed aspect ratio, such as knobs and meters).

Normally, each scaling operation would take place against the original layout, and this drift problem would be avoided. The problem happens, however, when you programmatically change the size or position of any part of a control. At that point, the record that contains the position of a given control in the original layout must be discarded and a new one created. When this happens frequently, and many of the controls in the panel are affected, repeated scalings can result in drift.

Many times, this is hard to avoid, since it might be impossible to avoid programmatically changing control positions in between consecutive scaling operations. But, on the off-chance that you might be able to avoid it, here is the list of attributes that, when changed, would cause CVI to discard the "original layout record" of the control:

ATTR_ANNOTATION_CAPTION_FONT
ATTR_ANNOTATION_CAPTION_POINT_SIZE
ATTR_ANNOTATION_XOFFSET
ATTR_ANNOTATION_YOFFSET
ATTR_AUTO_SIZING
ATTR_CELL_ARROW_HEIGHT
ATTR_CELL_ARROW_WIDTH
ATTR_COLUMN_LABELS_HEIGHT
ATTR_COLUMN_WIDTH
ATTR_CTRL_MODE
ATTR_DIG_DISP_HEIGHT
ATTR_DIG_DISP_LEFT
ATTR_DIG_DISP_TOP
ATTR_DIG_DISP_WIDTH
ATTR_FIT_MODE
ATTR_FRAME_THICKNESS
ATTR_GAUGE_FRAME_DIAMETER
ATTR_HEIGHT
ATTR_IMAGE_FILE
ATTR_INCDEC_WIDTH
ATTR_INCDEC_WIDTH_PRIVATE
ATTR_INDENT_OFFSET
ATTR_ITEM_HEIGHT
ATTR_LABEL_BOLD
ATTR_LABEL_FONT
ATTR_LABEL_HEIGHT
ATTR_LABEL_ITALIC
ATTR_LABEL_LEFT
ATTR_LABEL_POINT_SIZE
ATTR_LABEL_SIZE_TO_TEXT
ATTR_LABEL_STRIKEOUT
ATTR_LABEL_TOP
ATTR_LABEL_UNDERLINE
ATTR_LABEL_WIDTH
ATTR_LEFT
ATTR_LEGEND_HEIGHT
ATTR_LEGEND_LEFT
ATTR_LEGEND_NUM_VISIBLE_ITEMS
ATTR_LEGEND_TOP
ATTR_LEGEND_WIDTH
ATTR_MENU_ARROW_HEIGHT
ATTR_MENU_ARROW_WIDTH
ATTR_NUM_VISIBLE_COLUMNS
ATTR_NUM_VISIBLE_ROWS
ATTR_ORIGIN_MARKER_LENGTH
ATTR_PICT_BGCOLOR
ATTR_PLOT_FONT
ATTR_PLOT_ORIGIN
ATTR_PLOT_STYLE
ATTR_PLOT_THICKNESS
ATTR_RADIX_HEIGHT
ATTR_RADIX_WIDTH
ATTR_REFRESH_GRAPH
ATTR_ROW_HEIGHT
ATTR_ROW_LABELS_WIDTH
ATTR_SCALE_TICK_LENGTH
ATTR_SCROLL_BAR_SIZE
ATTR_SCROLL_BARS
ATTR_SHIFT_TEXT_PLOTS
ATTR_SHOW_DIG_DISP
ATTR_SHOW_INCDEC_ARROWS
ATTR_SHOW_RADIX
ATTR_SLIDE_INCDEC_LENGTH
ATTR_SLIDER_HEIGHT
ATTR_SLIDER_LEFT
ATTR_SLIDER_TOP
ATTR_SLIDER_WIDTH
ATTR_TABS_LOCATION
ATTR_TEXT_BOLD
ATTR_TEXT_FONT
ATTR_TEXT_ITALIC
ATTR_TEXT_POINT_SIZE
ATTR_TEXT_STRIKEOUT
ATTR_TEXT_UNDERLINE
ATTR_THERMOMETER_HOUSING_WIDTH
ATTR_TOP
ATTR_USE_PROGRESS_BAR_VISUAL_STYLES
ATTR_VISIBLE_LINES
ATTR_WIDTH
ATTR_XYLABEL_BOLD
ATTR_XYLABEL_CHARACTER_SET
ATTR_XYLABEL_FONT
ATTR_XYLABEL_ITALIC
ATTR_XYLABEL_POINT_SIZE
ATTR_XYLABEL_STRIKEOUT
ATTR_XYLABEL_UNDERLINE
ATTR_XYNAME_BOLD
ATTR_XYNAME_CHARACTER_SET
ATTR_XYNAME_FONT
ATTR_XYNAME_ITALIC
ATTR_XYNAME_POINT_SIZE
ATTR_XYNAME_STRIKEOUT
ATTR_XYNAME_UNDERLINE

[gdargaud]

Personally I prefer to list what I want to scale (graphs) and not (numerics, strings, etc). Catch resize panel callbacks and do some geometry with the new panel size to change the graph size.

But it's true that high dpi screens now make the text tiny. For this I have a function that explores all controls of all panels and change the font. It can be called with a menu or shortcut key.

[smartprogrammer]

The issue i am facing is very similar, i have used different PopUps and when there is a system with different resolution the issue i face is that if i resize my one window and open other window then there are two windows of same user interface with different sizes. how to have a user interface on which all popups and panels are on same resolution so that my user interface automatically adjusts to new system resolution.

[Layosh]

The only way you can do that is to build the user interface programatically. It is tedious and you will think twice to do that. The other way to cheat is have a resizeable main window and the others are child windows and the size issue will be a bit murky. Kind of hals a.s solution. Finally, you also can use windows sdk for the interface and the cvi libraries but it more or less defeats the reasons to use CVI.
I found this issue the biggest drawback for using Labwindows, but if you build system software you alwas can soecify your preferred hardware and stick to until you rebuild your software for the new display resolution.