Improves compatibility of controls with Windows visual styles (including the gradient background on XP); theme is enabled by default.

Most of these issues are caused by the Tab control being a "sibling" of the other controls. Tab3 solves this by putting controls inside a "tab dialog". This dialog is a sibling (not child) of the Tab3 control to allow the Tab3 control's tabs to accept focus. A few more tricks are used to get everything working and to adjust the backgrounds of controls to match the tab control.

Caveats:

Calling MoveWindow() on a control (via DllCall or WinMove, ahk_id %control_hwnd%, ...) will produce different results, since MoveWindow() expects coordinates relative to the control's parent, and the control's parent is the tab dialog. GuiControl Move and ControlMove are unaffected.

Custom controls which send notification messages to their parent window will work only if they use WM_COMMAND, WM_NOTIFY, WM_VSCROLL or WM_HSCROLL. These and any WM_CTLCOLOR' messages are forwarded to the main GUI, so can be intercepted by OnMessage. If the tab control is themed, WM_CTLCOLORSTATIC is fully handled by the tab dialog and not forwarded, unless the control has +BackgroundTrans.

The order in which the tab key cycles through controls may be different (and more sensible). Focus will move from the tabs, to the controls in the tab dialog, then out to the next control. Unlike Tab2, Tab3 does not put itself after the controls it contains.

Controls belonging to tabs can be placed outside the tab control only if they are added before the tab control exists (for simplicity).

Moving the Tab3 control will also move all of the controls which were placed inside it.

The test scripts demonstrate issues fixed by the control and how to utilize Tab3 without preventing the script from loading in older versions.

Re: New test build - Tab3 control

Controls belonging to tabs can be placed outside the tab control only if they are added before the tab control exists (for simplicity).

I dont think it's a good idea.

How can you add the Edit after the tab with y+10 if you dont know how big the Tab is on a non static Gui?

Re: New test build - Tab3 control

Posted: 21 Sep 2015, 04:33

by lexikos

The test scripts are there to demonstrate the behaviour; they are not expected to behave identically.

jNizM wrote:Than there should not be empty space under Tab3 control

You're right; it doesn't make much sense. It's probably best for controls in Tab3 controls to be ignored for the purposes of calculating the GUI height or the position of the next control not contained by a tab; the tab control itself should be considered instead.

Currently the control positioning is always relative to the previous control by default, even if it was in a tab, unless the new control is the first control in its tab.

jNizM wrote:I dont think it's a good idea.

It's not an idea; it's a fact.

Anyway, I think you're missing the point. Even if you place the control outside the display area of a Tab or Tab2 control, it still belongs to the tab control unless you've called Gui Tab to "disconnect" from the tab control. If you switch tabs, the control will disappear even though it sits outside the tab control. outside-tabs.ahk demonstrates this behaviour (but you have to switch tabs to see it).

I don't think it's a good idea to place controls that belong to a tab outside the tab control. I just mentioned it because of the possibility that users have used the tab control in very odd ways. For example, there is a script which gives the tab control zero dimensions and shows its own custom graphic buttons for switching tabs. That script could just continue using Tab/Tab2, or it could manually hide/show controls, but it's just one example. (Also, I intend there to be only one Tab control in v2, so simply using another type of Tab won't be an option.)

How can you add the Edit after the tab with y+10 if you dont know how big the Tab is on a non static Gui?

You can easily retrieve its size with GuiControlGet. Also, I think it's very uncommon to not specify the size of the tab control, since it isn't auto-sized like a GUI. Although it isn't a static size, it only depends on the font size and DPI (like the GUI margin), not the tab control's contents.

Also, it's actually very easy: just add the y+10 control after the tab control but before the tab's contents, as demonstrated by tab-order.ahk (#2 control). It messes up the tab order for Tab and Tab2, but Tab3 is okay.

Ideally the tab control could grow to fit its contents (auto-size like a GUI) and not need the size to be manually specified, but I hadn't seriously considered doing it due to complexity. Now that I think about it more, it would be very convenient and should be implemented before the stable release if it's going to be the default behaviour. There probably aren't any cases where the default size (as it's calculated now) is exactly right.

The clipping of controls in a Tab3 control can be useful; for example, when implementing scroll bars as illustrated by evilC in GUI in tab [Split from Tab3 announcement] (it was remiss of me to not mention this topic sooner).

Re: New test build - Tab3 control

Posted: 21 Sep 2015, 04:47

by jNizM

animatewindow.ahk (not about Tab3)
I saw with the old Tab the content is hiding after animatewindow.

Re: New test build - Tab3 control

Posted: 21 Sep 2015, 04:57

by lexikos

I'm not even remotely interested in debugging AnimateWindow. It is an antiquated API with two major by-design flaws: 1) It relies on the window and controls painting themselves correctly in response to WM_PRINT/WM_PRINTCLIENT messages. They don't, as you've noted. 2) It isn't compatible with the desktop window manager; i.e. the window frame reverts to the non-Aero Vista style while the window is animating (even on Windows 10).

For fading, WinSet Transparent on a timer works much better.

Re: New test build - Tab3 control

Posted: 27 Sep 2015, 07:00

by lexikos

v1.1.22.07-19+g6c206a4

Menu improvements:

Items can be identified by position with the Menu command. Use the same syntax as WinMenuSelectItem: 1&, 2&, etc.

ItemToInsertBefore is the name or position& of an existing item, or n& where n is the current number of items plus 1 (and is the same as omitting the parameter).

Menu M, Insert, , ... is the same as Menu M, Add, ..., except that if an item with that name already exists, Add modifies it whereas Insert creates a new item.

Added options for the Add and Insert sub-commands. The parameter formerly known as Pn can contain a list of options, with the same syntax as Gui/GuiControl: space/tab delimited, optional + or - prefix.

Improved Picture control to support BackgroundTrans with icons. (Omit AltSubmit for best results.)

The next two features are intended for any scripts or techniques which already deal with icon/bitmap handles (so you're expected to know what to do with the icon/bitmap). They can be used, for example, to set a window's icon with WM_SETICON or put a window's icon into a menu after retrieving it with WM_GETICON.

IconN: N is the icon number. If non-zero, the file must contain an icon.

GDI+: Use GDI+ if available.

ImageType receives the type of image: 0 (IMAGE_BITMAP), 1 (IMAGE_ICON) or 2 (IMAGE_CURSOR). If omitted or not a variable, the return value is always a bitmap handle (icons/cursors are converted if necessary).

The return value is a bitmap, icon or cursor handle (see above).

Commands and functions which load a picture, such as Gui Add, Picture, Menu M, Icon, ImageSearch, SplashImage, etc. now support passing an icon or bitmap handle. The syntax is HICON:handle or HBITMAP:handle (not case sensitive) in place of a filename. By default, AutoHotkey treats the handle as though it loaded the image from file itself -- deleting it automatically at some point, or perhaps immediately if it needs to be resized. To avoid this, put an asterisk between the colon and handle (and remember to delete the icon/bitmap at some point). For example: hbitmap:*%handle% (or "hbitmap:*" handle in an expression).

For a download link, see the top post.

Suggestions for syntax or behavioural changes are welcome (but not required).

v1.1.22.07 is just a minor bug-fix release and is unrelated to this thread. I uploaded it shortly before the test build, and forgot to announce it.

v1.1.22.07-19+g6c206a4 is a version string generated by git, which includes the most recent tag (v1.1.22.07), number of commits since that tag (19) and git commit (6c206a4). The stable release containing these new features will not be labelled v1.1.22.xx.

Because it's the default GUI name. Gui xxx: Default ordinarily sets the default name used by the Gui commands, regardless of whether any window "xxx" exists. It does not cause the window to be created, and if you pass a name or the HWND of a GUI which has a name, the setting persists even if you destroy and recreate the window. If you set an anonymous GUI as default and then destroy it, the default name reverts to "1".

The purpose of the variable is to allow scripts to save and restore the default GUI:

Using +hwndVarName will work, but it may create a window as a side-effect. This is wasteful and may affect the behaviour of the script.

Both +LastFoundExist and +hwndVarName would fail to work correctly if the window was destroyed in between retrieving the HWND and resetting the default, whereas using A_DefaultGui will properly restore the default Gui name.

No, as I demonstrated, it does not contain 1 if you change the default Gui. If you never change the default Gui, then obviously it is of no benefit to you, but it will be of benefit to others. (It also does not contain the same value as A_Gui if you have changed the default Gui.)

If you don't understand what the variable is for, you should review this post from last year and try to remember why you spent some of your time writing your own A_DefaultGui() function.

The purpose of these new variables is the same as for all of the previously existing thread settings: A_TitleMatchMode, A_KeyDelay, etc. If one is writing a function (or any self-contained portion of code) which requires changing a thread setting, one often wants to revert the setting afterward so as to not affect whatever code called the function. It's not necessary to use these variables directly in code which runs as its own thread (such as your timer and GUI threads), since any changes in that thread won't affect other threads.