Jump to content
BertKerkhof

Resizing the gui and docking

Recommended Posts

Dear people,

With a large window, more content fits in an edit box or list box. That gives the end-user more detail and overview. On the other hand, a small window is sometimes required, for example for display on a handheld or using multiple programs simultaneously on a desktop. It shows helpfulness to give the user optimum control over the size of the window.

Everyone knows awesome programs that would be even better if the size of the screen could be adjusted as desired. The AutoIT package offers support for this. With the GuiCtrlSetResizing function you can specify for each control how the dimensions will increase and how the position on the screen will change. With the Kodi Form designer there are nine bits to control resizing behavior, the so-called 'docking properties'. This means that for every control on the screen there are no less than 2 ^ 9 = 512 options. So much that it may be dazzling even for a programmer. Perhaps that is why the docking features are often not used.

The AutoIT package is sometimes compared with the famous Sagrada Família in Barcelona: it is never finished. This applies in particular to the RichEdit control, for which resizing did not work. The program below has been written to provide for this.

On the occasion, the docking model was examined: In fact, the 512 possibilities can be traced down to four practically usable ones for the x-axis and four for the y-axis. Together 4x4 = 16.

In the attached program they have the following names:

          xUpper, xLower, xMid, xStretch and

          yUpper, yLower, yMid, yStretch

Only one choice is required for each of the axes. It is a choice that excludes the other three. This makes the model understandable and ready for education. In addition, simplicity helps in writing and testing solid software.

The accompanying demo program only shows the resizing behavior of a single component. In practice, real world applications have many components on the screen. The structure of a sizable application window is as follows: 

·         One or more rows of components with docking yUpper

·         This can be followed by one row of docking yStretch

·         If necessary, one or more rows with docking yLower

 

Enhancement

With current resizing applications, there is often only one component that stretches with the window, usually a list box or an edit box or a video component.

For example if a program has both input and output, two stretching display components would be handy. Now that the dock model is so much simpler and more insightful, it could be expanded with four categories:

          xAboveMid, xBeneathMid and

          yAboveMid, yBeneathMid

All are of the stretch type, but each only takes up half the size change. They share the enlarged space. So AboveMid and BeneathMid belong together and deserve to be used together. The user friendliness increases in proportion to the extra surface. The following structure is possible with the new categories:

·         One or more rows of components with docking yUpper

·         This can be followed by one row with docking yAboveMid

·         If necessary, one row with docking yMid

·         Followed by one row with docking yBeneathMid

·         If necessary, one or more rows with docking yLower

 Note that with the proposed enhancement, there will be 6x6 = 36 docking categories, only 7 percent of the currently supported 512.

Enough words for today, below the demonstration program. Please respond to my proposal for simple and better docking categories.

          Bert

 

2019-11-27 PS:

Meanwhile an improvement is made: the resize demo now works flawlessly also if you drag the upper-left corner of the window.

On request: the necessary includes are directly downloadable here. Note that the latest versions are always present at GitHub: https://github.com/BertKerkhof

 

 

ResizeAndDock.au3 aDrosteArray.au3 StringSupport.au3

Edited by BertKerkhof
User request

Share this post


Link to post
Share on other sites

Seadoggie01, stay interested. What you asked for is now uploaded.

Resizing an external component parallel with build-in controls is just one issue that programmers have to face. The biggest challenge is that there simply aren’t enough hours in the day. 

The focus is on equipping the community with new ways by which the problems can be addressed. The problems you reported with include resources are covered by CircleCI, CodeTree and CodeClimate that run at GitHub. They service a build environment for integration, test and deployment. Many of these people work for free for open source projects. Haven't sorted out all of it but GitHub is the central place where my latest include versions are always published. So that a team can focus on making a great product.
 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...