Obsolete test build - Tab3 control with autosizing, SetTimer improvements

Community news and information about new or upcoming versions of AutoHotkey
just me
Posts: 5330
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

02 Oct 2015, 04:30

Wouldn't it be the same if A_Gui would be provided in non-GUI threads?
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

02 Oct 2015, 04:38

No, because then you could not retrieve the default GUI in a GUI thread.

A_Gui does not return the default GUI if the default GUI has been changed since the thread started. It always returns the GUI which launched the thread.
just me
Posts: 5330
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

02 Oct 2015, 05:08

Code: [Select all] [Download] GeSHi © Codebox Plus

GuiThread:
DefaultGui := A_Gui
; do what you want
Gui, %DefaultGui%:Default
; do what you want
Return

Anything wrong with this?

Edit: For the case that A_Gui will always contain the current default GUI.
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

02 Oct 2015, 06:23

There are plenty of cases where A_DefaultGui isn't needed. If you still don't get where it is needed, just move on.

As for your example, Gui, %A_Gui%: Default would always give the same result, provided that DefaultGui is never set anywhere else and GuiThread never interrupts itself.
just me
Posts: 5330
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

02 Oct 2015, 07:03

lexikos wrote:If you still don't get where it is needed, just move on.

Would you or anyone else please give an example, where a second variable A_DefaultGui has an advantage over one variable A_Gui changed to contain always each thread's current default GUI, or where the contents would differ when a thread is launched?
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

02 Oct 2015, 18:18

Did you not understand the phrase "just move on"?

A_Gui doesn't always contain the default GUI and can't be changed to do so without breaking scripts. Even if it could, changing it would mean that GUI threads would need to copy its value into another variable before changing the default GUI if they need to know which GUI launched the thread. It would also mean that A_Gui would be out of sync with all of the other A_Gui' variables, most importantly A_GuiControl.
just me
Posts: 5330
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

03 Oct 2015, 00:13

lexikos wrote:Did you not understand the phrase "just move on"?
Yes, I didn't.

lexikos wrote:There are plenty of cases where A_DefaultGui isn't needed.
I'd say that A_DefaultGui isn't needed in very most cases.

But I'm not interested enough to discuss this further.
jballi
Posts: 471
Joined: 29 Sep 2013, 17:34

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

03 Oct 2015, 03:17

One last kick of the dead horse...

Of course the A_DefaultGUI system variable is not needed. We've been doing without it for about 10 years. But I've got a sneaking hunch that it will be widely used. I plan to use it regularly. With the introduction of GUI (non-numeric) "names", knowing exactly what the default GUI "name" is becomes more important.

lexikos' fancymsgbox is a good example. It represent a call to an independent subroutine or function that creates a new GUI. I create these functions all the time. I even have one that creates a fancy MsgBox. I work very hard to ensure that the default GUI is not modified because it could affect the calling script after the function returns. With the new A_DefaultGUI system variable, the gui syntax could be written more generically because the "gui xxx:Default" command could be used and the function could ensure that that calling script is not affected by resetting default GUI before the function returns. Yes, there are other considerations but this is the short of it.

When writing independent routines, probably the most value can be found when commands that only operate on default GUI are used. With ListView (Ex: LV_GetText), TreeView (Ex: TV_GetNext), and status bar (Ex: SB_SetText) commands are used, the developer has no choice but to set the default GUI before calling these commands. With the new A_DefaultGUI system variable, the developer can reset the default GUI after any of these commands are called. And yes, the new A_DefaultListView system variable could come into play with the ListView commands and the new A_DefaultTreeView system variable could come into play for the TreeView commands.

Them be my thoughts. My condolences and apologies for the dead horse.
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

03 Oct 2015, 03:50

just me wrote:I'd say that A_DefaultGui isn't needed in very most cases.
Very most of the built-in variables aren't needed in very most cases, but in specific situations. Every variable has limited usefulness. No single thing is going to accomplish every task.
just me
Posts: 5330
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

03 Oct 2015, 03:56

jballi wrote:It represent a call to an independent subroutine or function that creates a new GUI. I create these functions all the time. I even have one that creates a fancy MsgBox. I work very hard to ensure that the default GUI is not modified because it could affect the calling script after the function returns. With the new A_DefaultGUI system variable, the gui syntax could be written more generically because the "gui xxx:Default" command could be used and the function could ensure that that calling script is not affected by resetting default GUI before the function returns. Yes, there are other considerations but this is the short of it.

And you are calling these functions only within the auto-execute section?
jballi
Posts: 471
Joined: 29 Sep 2013, 17:34

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

03 Oct 2015, 04:16

just me wrote:And you are calling these functions only within the auto-execute section?

They can be called from anywhere but no, they are almost never called within the auto-execute section of a script.
just me
Posts: 5330
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

03 Oct 2015, 04:46

@jballi:
GUI Events, Threads, and Subroutines

A GUI thread is defined as any thread launched as a result of a GUI action. GUI actions include selecting an item from a GUI window's menu bar, or triggering one of its g-labels (such as by pressing a button).

The default window name for a GUI thread is that of the window that launched the thread. Non-GUI threads use 1 as their default.

The built-in variables A_Gui and A_GuiControl contain the window name and Control ID that launched the current thread. For details see A_Gui and A_GuiControl.
As a result of my testing this has not been changed in the test build. At the moment the thread is launched, A_DefaultGui equals A_Gui in GUI threads and OnMessage() functions, and contains always 1 in non-GUI threads (e.g. Timers). Also, A_DefaultGui will change as soon as a new default Gui is created. So you have to save it before you do it if you want to reset the default Gui afterwards.
jballi
Posts: 471
Joined: 29 Sep 2013, 17:34

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

04 Oct 2015, 00:39

Not a great real-life example but it may give you an idea of how the A_DefaultGUI system variable could be useful. This script should be run-able on the latest test build.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

User avatar
Alguimist
Posts: 222
Joined: 05 Oct 2015, 16:41

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

06 Oct 2015, 14:40

With the advent of Tab3, the Tab2 will not be deprecated though, because it allows controls to be created outside the tab control, which can be very useful in some cases, for example, in a settings dialog, as follows:

Image

FileZilla Settings.ahk
(39.97 KiB) Downloaded 320 times
jballi
Posts: 471
Joined: 29 Sep 2013, 17:34

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

07 Oct 2015, 00:03

Trying to test the new menu options. I don't seem to understand the new Right option. For the most part, it doesn't appear to do anything. The only time it did anything was when it was followed by new menu item that contained the "Break" or "BarBreak" options.

Here is my example:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



Can anyone lead me in the Right direction? Thanks.
lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

07 Oct 2015, 00:50

@jballi: It is for menu bars, not popup menus.
Right: The item is right-justified within the menu bar (on a Gui).

For example, apply it to the "Edit" item.
jballi
Posts: 471
Joined: 29 Sep 2013, 17:34

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

07 Oct 2015, 02:25

Interesting. And it automatically moves when the window is resized. Also, any menu item added after a "Right" item, is added to the "right justified" group.
just me
Posts: 5330
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

08 Oct 2015, 07:42

Hello lexikos!

Since you are working on the Pic controls:

Updating the contents of a Pic control containing an image often causes an unwanted flickering. IMO, this is caused by the fact, that the control's bitmap is set to NULL before the new bitmap is loaded

Code: [Select all] [Expand] [Download] (script_gui.cpp)GeSHi © Codebox Plus

which seems to redraw the control immediately.

As a result of my testing this doesn't seem to have been changed in the test build. Can it be changed, at least for bitmaps?

Example:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

lexikos
Posts: 5896
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars

08 Oct 2015, 19:15

just me wrote:Since you are working on the Pic controls:
No. I was, for a short time a few weeks ago.
IMO, this is caused by the fact, that the control's bitmap is set to NULL before the new bitmap is loaded
If that was the cause, you could just set the bitmap via STM_SETIMAGE. Avoiding the intermediate STM_SETIMAGE does not help - the control still flickers.

Return to “Announcements”

Who is online

Users browsing this forum: No registered users and 1 guest