GUI in tab [Split from Tab3 announcement]

Get help with using AutoHotkey and its commands and hotkeys
User avatar
evilC
Posts: 4354
Joined: 27 Feb 2014, 12:30

GUI in tab [Split from Tab3 announcement]

19 Sep 2015, 05:59

[Moderator's note: Topic split from New test build - Tab3 control.]

Very interesting - my new RADical project puts a bunch of stuff inside Tabs, so I am happy to see improvements being made to them :)

I like how if the contents of a Tab3 are bigger than the tab, that they are clipped by the boundary of the tab.

I am not up to speed on the implications of what a "Sibling" window is, but I wondered if Tab3 may help streamline a technique I am using for RADical...

Basically, I want to make tabs that have scrollbars inside. This is the effect I wish to achieve:
Image

I am happy with having to embed a child Gui inside the Tab, but currently I have to add a textbox inside the tab and parent the child Gui to that:

Code: Select all

#SingleInstance force

Gui, +HwndhMain
Gui, Add, Tab3, w300 h200, A|B

Gui, Add, Text, w280 h180 hwndhFrameA
Gui, new, hwndhChildA -Caption
Gui, % "+Parent" hFrameA
Gui, Color, FF0000
Gui, Show, w280 h180 x0 y0
Gui, Add, Text, x0 y0, This was Added at x0 y0

Gui, % hMain ":Tab", B

Gui, % hMain ":Add", Text, w280 h180 hwndhFrameB
Gui, new, hwndhChildB -Caption
Gui, % "+Parent" hFrameB
Gui, Color, 0000FF
Gui, Show, w280 h180 x0 y0
Gui, Add, Text, x0 y0, This was Added at x0 y0

Gui, % hMain ":Show", x0 y0
I was wondering if the Tab3 would let me do away with the Textbox "Frame"?

Apologies for derailing your thread a little...
lexikos
Posts: 6205
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: New test build - Tab3 control

19 Sep 2015, 07:22

I don't mind the derailing, except for the GIF, which I've spoilerized (edit: undone after moving the topic).

You don't actually have to parent the GUI to a text control. The tab control works by hiding and showing controls when the tab selection changes. You can do the same using the g-label of the tab control. However, adding a control in place of the GUI is useful for reserving space if you want to add other controls after it.

I thought about another system, where each tab is actually a GUI with its own set of options and control-positioning variables. That way you can create or destroy tab pages (and GUIs) at will. However, I thought it wouldn't make a lot of sense for the controls in the tab to not be considered controls of the main GUI.

FYI, tab controls are typically used that way:
You must process TCN_SELCHANGE to display the incoming page in the display area. This might simply entail changing the information displayed in a child window. More often, each page consists of a child window or dialog box. In this case, an application might process this notification by destroying or hiding the outgoing child window or dialog box and by creating or showing the incoming child window or dialog box.
Source: About Tab Controls (Windows)
Tab3 only uses one dialog, and hides and shows controls as before. So no, I don't think it really helps your situation.
User avatar
evilC
Posts: 4354
Joined: 27 Feb 2014, 12:30

Re: New test build - Tab3 control

19 Sep 2015, 08:29

So the way RADical is designed is that the RADical lib creates a "frame" around your script - ie it makes the tab control, adds the "Profiles" tab and puts the profile selection controls into that.
The "Client" script can then add it's own tabs (in my GIF, Tab A and B) and all it's guicontrols live on one of the "Client" tabs. As far as the Client script is concerned, x0 y0 should be the top left of one of the Client tabs.

Currently, I have to call a pre-determined method of the Client script (Config()) to let the client script specify which tabs it wants (ie A and B) before I create the Tab control, so being able to dynamically add new tabs to the control after it is created would improve usability somewhat, allowing me to remove this step from the "Start Up" process (The only other thing in there is setting the title of the Gui, which could be done after Gui, Show).

Whilst I can appreciate what you said about alternatives to parenting the child Guis to TextBoxes, it seems to me that if you implemented some system of being able to dynamically add tabs, then it would be possible to craft a tab control that when you dynamically created a tab, the hwnd option could return the hwnd of a child gui inside that tab. I suppose that still leaves the case of where you initialize the tab control with multiple tabs using one command, but maybe a new option could be added (eg ChildHwnds that worked something like this:

Code: Select all

Gui, Add, GuiTab, xm ym w300 h200 ChildHwndshTabs, A|B  ; This creates a tab with two tabs, each with it's own Child Gui
; hTabs would be like "0x12345|0x67890", or maybe an array [0x12345|0x67890]
Gui, GuiTab, B ; The child Gui of Tab B is now the default Gui
Gui, Add, Edit, x0 y0 w200 ; this is placed at x0 y0 of the child gui of Tab B
An alternative may be:

Code: Select all

Gui, Add, GuiTab, xm ym w300 h200 hwndhTab, A|B  ; This creates a tab with two tabs, each with it's own Child Gui
; hTab would be the hwnd of the Tab control, as normal
Gui, GuiTab, B ; The child Gui of Tab B is now the default Gui
Gui, +HwndhChildB
; hChildB would now be the hwnd of the Child Gui of Tab B
Gui, Add, Edit, x0 y0 w200 ; this is placed at x0 y0 of the child gui of Tab B
The other consideration maybe worth mentioning is the scrollbars.
HotkeyIt and I are currently working on adding scrollbar support to the AHK_L source (Pull request should hopefully be incoming by the end of the weekend), but one concern that I have is that if you have two tabs, both with child guis that contain scrollbars - only one of the child guis can be visible at one time - so if you resize the whole Gui (thus resizing the tab control, as it grows to fill the whole area of the main Gui), it would not make sense to update the PAGE and RANGE of the scrollbars for both tabs, as it would be wasteful of CPU cycles to update the scrollbars for non-visible tabs.

Thoughts?

PS, I am happy to move this discussion off to another thread if you wish, please feel free to moderate it out.
lexikos
Posts: 6205
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: GUI in tab [Split from Tab3 announcement]

19 Sep 2015, 17:48

I have split the topic. Feel free to edit the title.
Whilst I can appreciate what you said about alternatives to parenting the child Guis to TextBoxes, it seems to me that if you implemented some system of being able to dynamically add tabs,
It seems to me that such a system has already been implemented. It's called "GuiControl".

All you need to do is position the child GUIs in the right place and hide/show them when the tab selection changes. You can use the TCM_ADJUSTRECT message to calculate the position.

A different, more general, idea that I've had prior to this discussion is to create a new type of control which is really just a GUI. In other words,

Code: Select all

Gui Add, Gui, <options>, <either the title or the name>
The purpose of this would mainly be for positioning the GUI and reserving that space (for positioning other controls). Since it would be considered a control, the Tab control would automatically manage it. You'd just have to add one GUI control to each tab.

(Actually, it might be difficult to allow GUI options, since it needs to accept at least some control options.)
lexikos
Posts: 6205
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: GUI in tab [Split from Tab3 announcement]

19 Sep 2015, 18:01

... it would not make sense to update the PAGE and RANGE of the scrollbars for both tabs, as it would be wasteful of CPU cycles to update the scrollbars for non-visible tabs.
You could always postpone resizing of each tab until the tab becomes visible.

If the child GUI handles its own scrollbars when the child GUI itself is resized, just have the main GUI resize the visible child GUI when the window is resized, and resize (if necessary) each child GUI when it is shown by selecting that tab.

Btw, the controls are disabled when hidden to ensure that they can't be activated by keyboard shortcuts. It wouldn't be necessary if the GUI which contains the controls is disabled instead. However, the controls still need to be disabled individually if the tab control is disabled, otherwise their appearance won't change to reflect the fact that you can't interact with them.
HotKeyIt
Posts: 1705
Joined: 29 Sep 2013, 18:35
Contact:

Re: GUI in tab [Split from Tab3 announcement]

14 Oct 2015, 02:18

A different, more general, idea that I've had prior to this discussion is to create a new type of control which is really just a GUI. In other words,

Code: Select all

Gui Add, Gui, <options>, <either the title or the name>
The purpose of this would mainly be for positioning the GUI and reserving that space (for positioning other controls). Since it would be considered a control, the Tab control would automatically manage it. You'd just have to add one GUI control to each tab.

(Actually, it might be difficult to allow GUI options, since it needs to accept at least some control options.)
How about to allow to allow adding existing GUI to controls Gui Add, Gui, <control options>, <either the hwnd or the name of existing GUI>?

Code: Select all

Gui, 2:Add, Edit, w100 h100,Test
Gui, 2:-Caption
Gui, 2:Show, Hide
Gui, Add, Gui,,2
lexikos
Posts: 6205
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: GUI in tab [Split from Tab3 announcement]

14 Oct 2015, 03:12

That's a better idea. Feel free to do up a prototype if you think it is worthwhile.

Return to “Ask For Help”

Who is online

Users browsing this forum: Bing [Bot], Boxof, kadhri, roysubs and 110 guests