Obsolete test build - Tab3 control with autosizing, SetTimer improvements

Community news and information about new or upcoming versions of AutoHotkey
just me
Posts: 5512
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: 6176
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: 5512
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

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: 6176
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: 5512
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: 6176
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: 5512
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: 498
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: 6176
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: 5512
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: 498
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: 5512
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: 498
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

#NoEnv
#SingleInstance Force

;-- Add new code here
gui PrimaryGUI:Default
gui -DPIScale +LabelPrimaryGUI_ -MinimizeBox
gui Add,Text,xm,
   (ltrim
    Although not a great IRL example, the status bar on the Primary
    GUI is updated while creating the GUI2 window.
   ) 
gui Add,Checkbox,Checked vUse_A_DefaultGUI,Use A_DefaultGUI to restore the default GUI
gui Add,Checkbox,vUseSetTimer,Use an independent thread (i.e. SetTimer) to update the status bar
gui Add,Button,xm gGUI2,%A_Space%  GUI2  %A_Space%
gui Add,Button,xm gReload,%A_Space%  Rebuild example...  %A_Space%
gui Add,StatusBar
gui Show,,PrimaryGUI
SBText :="PrimaryGUI built"
gosub UpdateSB
return
;-- End of new code


PrimaryGUI_Close:
PrimaryGUI_Escape:
ExitApp


Reload:
Reload
return


UpdateSB:
if UseSetTimer
    SetTimer %A_ThisLabel%2,1
 else
    gosub %A_ThisLabel%2

return


UpdateSB2:  ;-- Uses SBText global variable
SetTimer,,Off
outputdebug A_DefaultGUI=%A_DefaultGUI%

;-- Save the default GUI
SavedDefaultGUI :=A_DefaultGUI

;-- Set default GUI
gui PrimaryGUI:Default
    ;-- SB_SetText ONLY works on the default GUI so the default GUI
    ;   must be set here in order for the command to work every time.

SB_SetText(SBText)

;-- If requested, restore default GUI
if Use_A_DefaultGUI
    gui %SavedDefaultGUI%:Default

return


GUI2:
gui Submit,NoHide
gui GUI2:Default
gui PrimaryGUI:+Disabled
gui +OwnerPrimaryGUI
gui +LabelGUI2_ -MinimizeBox
gui Font,s26
gui Add,Text,xm,Line 1
gui Show
SBText :="GUI2: Line 1 Added"
gosub UpdateSB
Sleep 750
gui Add,Text,xm,Line 2
SBText :="Line 2 Added"
gosub UpdateSB
gui Show,AutoSize
Sleep 750
gui Add,Text,xm,Line 3
SBText :="Line 3 Added"
gosub UpdateSB
gui Show,AutoSize
return

GUI2_Close:
GUI2_Escape:
gui PrimaryGUI:-Disabled
gui Destroy
return
User avatar
Alguimist
Posts: 297
Joined: 05 Oct 2015, 16:41
Contact:

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 328 times
jballi
Posts: 498
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

#NoEnv
#SingleInstance Force

Menu MyMenu,Add,Menu Item 1,MyMenuAction,Right
Menu MyMenu,Add,Menu Item 2,MyMenuAction,Break
Menu MyMenu,Check,Menu Item 2
Menu MyMenu,Add,Menu Item 3,MyMenuAction,Radio
Menu MyMenu,Check,Menu Item 3
Menu MyMenu,Add,Menu Item 4,MyMenuAction,Right
Menu MyMenu,Add,Menu Item 5,MyMenuAction

Menu MenuBar,Add,Edit,:MyMenu

gui -DPIScale -MinimizeBox
gui Menu,MenuBar
gui Show,w300 h300
return


GUIClose:
GUIEscape:
ExitApp


MyMenuAction:
return


GUIContextMenu:
Menu MyMenu,Show
return
Can anyone lead me in the Right direction? Thanks.
lexikos
Posts: 6176
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: 498
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: 5512
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

			// The below must be done only after the above, because setting the control's picture handle
			// to NULL sometimes or always shrinks the control down to zero dimensions:
			// Although all HBITMAPs are freed upon program termination, if the program changes
			// the picture frequently, memory/resources would continue to rise in the meantime
			// unless this is done.
			// 1.0.40.12: For maintainability, destroy the handle returned by STM_SETIMAGE, even though it
			// should be identical to control.union_hbitmap (due to a call to STM_GETIMAGE in another section).
			if (control.union_hbitmap)
				if (control.attrib & GUI_CONTROL_ATTRIB_ALTBEHAVIOR) // union_hbitmap is an icon or cursor.
					// The control's image is set to NULL for the following reasons:
					// 1) It turns off the control's animation timer in case the new image is not animated.
					// 2) It feels a little bit safer to destroy the image only after it has been removed
					//    from the control.
					// NOTE: IMAGE_ICON or IMAGE_CURSOR must be passed, not IMAGE_BITMAP.  Otherwise the
					// animated property of the control (via a timer that the control created) will remain
					// in effect for the next image, even if it isn't animated, which results in a
					// flashing/redrawing effect:
					DestroyIcon((HICON)SendMessage(control.hwnd, STM_SETIMAGE, IMAGE_CURSOR, NULL));
					// DestroyIcon() works on cursors too.  See notes in LoadPicture().
				else // union_hbitmap is a bitmap
					DeleteObject((HGDIOBJ)SendMessage(control.hwnd, STM_SETIMAGE, IMAGE_BITMAP, NULL));
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

#NoEnv
SetBatchLines, -1
Pics := []
Loop, Files, %A_WinDir%\Web\Wallpaper\*.jpg, R
{
   Pics.Push(A_LoopFileLongPath)
   If (Pics.Length() > 2)
      Break
}
Gui, Add, Pic, w600 h-1 vPic +Border, % Pics.1
GuiControl, +0x40, %HPIC%
Gui, Show, , Test
Sleep, 1000
GuiControl, , Pic, % Pics.2
Return
GuiClose:
GuiEscape:
ExitApp
lexikos
Posts: 6176
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 3 guests