Obsolete test build - Tab3 control with autosizing, SetTimer improvements
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
Wouldn't it be the same if A_Gui would be provided in non-GUI threads?
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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.
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.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
Code: Select all
GuiThread:
DefaultGui := A_Gui
; do what you want
Gui, %DefaultGui%:Default
; do what you want
Return
Edit: For the case that A_Gui will always contain the current default GUI.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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.
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.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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.
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.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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.
But I'm not interested enough to discuss this further.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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.
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.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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?
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
@jballi:
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.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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:
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
Is FileZilla written in AHK?
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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:
Can anyone lead me in the Right direction? Thanks.
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
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
@jballi: It is for menu bars, not popup menus.
For example, apply it to the "Edit" item.Right: The item is right-justified within the menu bar (on a Gui).
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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.
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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 loadedwhich 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:
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));
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
Re: New test builds - Tab3 control, Menu improvements, LoadPicture, new vars
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