HotkeyIt and I are working on improving AHK's support for resizable Guis, we have so far implemented ScrollBars, an auto-positioning system, and adding child Guis as GuiControls. We have provided a test build of AHK in the hope that people can help test it, and provide feedback.

Controls can be automatically repositioned and resized relative to the Gui size.
The first time the Gui is shown, the size of each control becomes the "default size"; controls are resized and repositioned only when the Gui becomes larger than the initial size and relate always to the initial size. This is to allow you to define a minimum usable size for each control.
Resizing and repositioning values can be an integer (2), float (0.5) or fraction (1/3), negative values are also supported.
When no value is given it defaults to 1, so ax equals ax1 and ax1/1 and ax1.0
Note: the order in which controls are created is important if you want to align to previously repositioned controls.

The following options are supported to resize and reposition controls automatically:

AX: Reposition control horizontally, for example ax1/3
AY: Reposition control vertically, for example ay0.5
AW: Resize control width, for example aw0.5
AH: Resize control height, for example ah0.5
AXP: Use previous control position horizontally.
AYP: Use previous control position vertically.
AXA: Auto-Position X. Control will be placed to the right of the previous control.
AYA: Auto-Position Y. Control will be placed below the previous control.
AWA: Auto-Width. Control will be scaled by the same amount as the last control that used AW.
AHA: Auto-Height. Control will be scaled by the same amount as the last control that used AH.

Resetting horizontal and vertical alignment

Resetting alignment is necessary to start a new section of controls which will not consider changed position of previous controls.
For example when you add controls in a row and start a new row you will need to reset horizontal value so the new row will not consider moved position of previous row which is used to align controls.

Child Guis as GuiControls
Syntax: Gui, Add, Gui, <control options>, <hwnd or name/number of existing Gui>
This adds an existing Gui, as if it were a GuiControl.
You can use the guicontrol options to apply autopositioning values to the child Gui.

Using the test build
You can either replace your AutoHotkey.exe with the one in the attached ZIP, or simply extract the ZIP and double-click AutoHotkey.exe to run AutoHotkey.ahk with the EXE in the same folder.
An AutoHotkeySC.bin is included if you wish to compile scripts using it.
The ZIP contains Unicode 32 bit files only.

[*]Finalize mouse wheel scrollbar support (Must Have).
The current code is just a placeholder. I have a solution in mind here - scroll the HWND under the mouse cursor. I seem to remember using this technique in an implementation written in AHK and IIRC it worked OK.

Reduce flicker (Should Have)
Controls can flicker sometimes on resize - we will look into ways to reduce this.[*]Child Gui support (Could Have - though can be quite easily done in AHK code).
Add auto-size / auto-positioning for child Guis (Guis parented to other Guis with +Parent). Also, parents consider children's size with respect to scrollbars.
This would open up numerous exciting possibilities - eg:
Scrolling sub-sections (header, footer, with scrolling mid-section etc)
Better support for resizing groupboxes / tabs (The contents of the groupbox or tab could be positioned and sized relative to the tab)

ListView etc column sizing (Might Have)
Some way to define how columns of a listview change width when it sizes would be a nice touch.[*]Tab control with scrolling content (Might Have)
Some way to avoid having to parent a child Gui to a textbox in order to achieve a tab control with scrolling contents.

My aim is to get it into AHK_L - I feel it belongs there.
If you do not want it, don't use it. But if you do want it, implementing it is way beyond most users' abilities and requires a bunch of steps that are simply not needed if you do it in the AHK source.

yes of course, it would be a great addition to have built-in support for this. lexikos has been reluctant to merge changes in from AHK_H that add important features, but maybe he will accept this. if not, having the built-in support in AHK_H would be a nice alternative

evilC wrote:The scrollbars don't quite disappear early enough yet - if removing the scrollbar would give enough space for the entire Gui to be visible, they don't disappear until the scrollbars no longer overlap the Gui.

That doesn't seem to be the case with the current version on my system. If the GUI without scrollbars would be large enough to fit the controls, the scroll bars are removed.

Edit: I think the margins should be taken into consideration. As it is, the edges of some controls get clipped by the scroll bar. (It also lacks symmetry...)

+HScroll, +VScroll options added to only enable scrollbars for one axis.
-Scroll implemented (Removes scrollbars and scrolls Gui back to start)
Scrollbars now disappear when the client rect + scrollbar area would accommodate gui.
Plus some fixes and code tidies.

evilC wrote:The scrollbars don't quite disappear early enough yet - if removing the scrollbar would give enough space for the entire Gui to be visible, they don't disappear until the scrollbars no longer overlap the Gui.

That doesn't seem to be the case with the current version on my system. If the GUI without scrollbars would be large enough to fit the controls, the scroll bars are removed.

Yup, HotkeyIt fixed this

lexikos wrote:Edit: I think the margins should be taken into consideration.

This screenshot is with Gui, Margin, 0, 0 set and seems fine.

This is with Gui, Margin, 5, 5 set. Again, seems good.
Also, Gui, Show in this SS had no width or height specified, yet it allocated space for the scrollbars. This maybe needs looking into.

lexikos wrote:As it is, the edges of some controls get clipped by the scroll bar. (It also lacks symmetry...)

Obviously, taking the margins into consideration (for symmetry) is unnecessary if you remove the margins.

It seems "fine" (aside from the lack of symmetry) on Windows 8 and Windows 10, which have flat, clearly defined rectangular borders. On my Windows 7 work PC (which I am not on right now), the bottom edge of the last Edit control is not visible.

Even when the window has scroll bars, there is a margin at the top left of the controls but none at the bottom right.

Tested on Windows 7. Seems to work well. My mouse has a scroll left/right feature, and while the support is only "rudimentary" at this time, I still wanted to note that clicking the scroll left will make the GUI scroll to the right, and clicking the scroll right will make the GUI scroll to the left -- opposite directions.

Added a new release with a preview of our new Auto-Positioning system.
The AutoPos system knows how much previous controls moved by, and is intended to make it easy to have controls move based upon how much previous controls moved / grew.

This is currently heavily WIP, and we are looking to make changes to how it works (eg remove the need for the ax/ay params in most cases)

We have added some more options: AXA, AYA, AWA + AHA.
AXA+AYA allow you to easily position controls to the right / below existing controls, negating the need to specify an exact amount to move using AX / AY.

AWA + AHA allow you to repeat the same width or height factor on subsequent controls.
This is useful if you, for example, decide to add another row or column in an evenly distributed layout (ie all widths or heights grow by same amount) - you would now only need to change the AW / AH fraction for the first item in the row / column, and the rest would use the value of the first item.

Okay this looks great so far! I really appreciate your work.
So here is what I was talking about in the other thread. I'd really like to see something that makes the use of tabs and groupboxes easier.
-make it easy to add an element to a group/tab
-make elements align automatically within the tab
-automatically adjust the tab width to fit the content OR automatically rearrange the content to be visible

Something else that would be interesting is this kind of auto resizing: https://jsfiddle.net/UNs25/1/embedded/result/
(If you make your browser window smaller, the editboxes arrange in a different way.)
This is obviously more interesting for tablets (and for phones.. once we actually get x86/x64 phones which is Q2 2016 or so.)

HotkeyIt's examples seem to be what you want - Although I am not too happy with the way the scrollbars appear on resize, I guess you would need to force the groupbox / tab to be slightly smaller than the initial size of the GUI.

Regarding the "responsive" layout link you posted - no, that is way outside the scope of the current system I am afraid.
I am not sure we could work that kind of behaviour in, it would be fundamentally different code to what we have.

Hm, yeah, It's pretty much what I asked for, but in the end I'd like to be able to
-extend the content of a tab/group box without much thinking and without changing other elements.
-add more group boxes and be able to change the order of them without any problems.

At the moment there are two things that I can present that I'd like to accomplish:http://jsfiddle.net/5jppbqqk/4/ (change the width and see what happens)
fixed sized group boxes (as many as I want) and their positions are arranged automatically depending on where is enough free space in the GUI

And here is another thing: http://i.snag.gy/8gM1f.jpg
This GUI does not resize or anything and chances are that I'll never change it again because changing one thing means changing everything.
I'd really to rewrite this whole thing to have the left side being able to resize in width and everything to resize in height when changing the window size.
And I'd also like to not worry about margins between any controls and have elements easily scaled to 100% (minus margins) inside a group box etc..

Bruttosozialprodukt wrote:
-extend the content of a tab/group box without much thinking and without changing other elements.

The new axa, aya, awa, aha options are our attempt to alleviate this issue.

Bruttosozialprodukt wrote:
-add more group boxes and be able to change the order of them without any problems.

Our system merely works by "deviation from initial position" - everything only moves by a factor of how much the GUI grew.
Stuff like this is probably not within the scope of our system.
However - if you wish to do stuff like this, there is nothing stopping you from embedding a child GUI within a parent GUI (Gui +parent option)- each groupbox could be a separate GUI, with our system handling the layout within the child gui. I have plans to add child Guis to the auto-positioning system (Allow auto-scaling of a child gui to fit change in size of parent gui), so hopefully this would satisfy that requirement.

Bruttosozialprodukt wrote:
At the moment there are two things that I can present that I'd like to accomplish:http://jsfiddle.net/5jppbqqk/4/ (change the width and see what happens)
fixed sized group boxes (as many as I want) and their positions are arranged automatically depending on where is enough free space in the GUI

Bear in mind that it is possible to use HTML / JS in AHK guis. It's not something I have any experience in, but it can be done.

Bruttosozialprodukt wrote:
And I'd also like to not worry about margins between any controls and have elements easily scaled to 100% (minus margins) inside a group box etc..

As mentioned, if we can get auto-sizing of child GUIs working, that should allow you to do this.