Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
Posted: 02 Oct 2015, 04:30
Wouldn't it be the same if A_Gui would be provided in non-GUI threads?
Let's help each other out
https://www.autohotkey.com/boards/
Code: Select all
GuiThread:
DefaultGui := A_Gui
; do what you want
Gui, %DefaultGui%:Default
; do what you want
Return
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 wrote:If you still don't get where it is needed, just move on.
Yes, I didn't.lexikos wrote:Did you not understand the phrase "just move on"?
I'd say that A_DefaultGui isn't needed in very most cases.lexikos wrote:There are plenty of cases where A_DefaultGui isn't needed.
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 wrote:I'd say that A_DefaultGui isn't needed in very most cases.
And you are calling these functions only within the auto-execute section?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.
They can be called from anywhere but no, they are almost never called within the auto-execute section of a script.just me wrote:And you are calling these functions only within the auto-execute section?
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.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.
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
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
For example, apply it to the "Edit" item.Right: The item is right-justified within the menu bar (on a Gui).
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));
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
No. I was, for a short time a few weeks ago.just me wrote:Since you are working on the Pic controls:
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.IMO, this is caused by the fact, that the control's bitmap is set to NULL before the new bitmap is loaded