Screen layout issues

Archived Topics
1

I’ve been spending a bit of time looking at screen layouts within FactoryPMI. This post is a description of what I’ve found, hopefully to help anyone in the same situation and in case someone can see room for improvement in what I’m doing.

Systems we install usually end up with a buttonbar at the bottom of the screen to allow users to display the required mimic (window in FPMI speak) in the main part of the screen. This is described in the FPMI documentation in Concepts/Windows/Navigation as a Docked Navigation Pane. We implemented this using the Navigation Script Module so that the correct window will be replaced when a navigation button is pressed. So far so good.

Potential problems arise when allowing users to run at other resolutions than the one designed for. To make the main window fill the space available, its Start Maximised property has to be set to true. This means that the buttonbar has to be a docked window, otherwise it is covered by the main window. If the user resizes the application, the main window will resize and move its contents in both directions (assuming relative layout by default), but the buttonbar will only resize in one direction – if docked south it will resize left and right but not up and down.

This means that items in the main window (such as other buttons) which were lined up with buttons in the buttonbar will lose alignment. I got round this problem by anchoring the buttons in both the buttonbar and the main window to the bottom left of each window. This way the buttons stay in line and don’t resize along with their window. Other buttons on the right of the screen can be anchored to the bottom right of their window. In this situation, you have to be careful not to let the window get so small that the items anchored to the left and right of the window collide in the middle. This can be set using the Project’s Minimum Size properties.

What I’ve found helpful is sizing the windows so that they fit neatly into the normal resolution they will be running at. When running windowed in standard XP at 1024 x 768, existing borders and titlebar etc. mean that windows should be no wider than 1012 and no taller than 706 – if the main window sits above the buttonbar, the height of both windows added together must equal 706. Applications designed at this size with buttons anchored as required seem to scale up in size well and scale down to 800 x 600 (788 x 538 in standard XP) without any great issues, as long as you can accommodate the contraction of your buttonbar.

I hope this post is not too confusing and that it helps someone else :slight_smile:

2

Great points!

A few things to consider about layout:

  1. Layout settings are always with respect to the selected object’s parent container. In many cases this ends up being the root container.
  2. Relative layout is what it is, and generally would be the preferred choice for people who don’t use layout. Beyond single window “panelview” style applications, I typically use anchored.
  3. Good observation with the project minimum size property. Windows also have a minimum and maximum size as expert properties.
  4. The animated image on this post provides an example of using containers and layout that you may find interesting.

As far as docked windows go:

  1. A docked window with buttons and global status indication can work well. If you want it to feel “seamless”, similar to framed web pages, make sure that you don’t display the border or titlebar and that the “main” window is maximized.
  2. I’ll look into a window docking mode that respects relative layout. My guess is that it would resize in the “other” direction, but would probably not align objects within the window as nicely as you would expect. This will turn into a feature request if it’s viable.

Thanks for the input!

3

I just want to point out that the Skeleton Project (available as a goodie here) is a great starting point for the (extremely common) docked-windows plus main window navigation style.