Re: New test build - Tab3 control with autosizing, SetTimer improvements
Posted: 14 Mar 2016, 07:34
How about a new BIV A_ThisTimer providing all kinds of timers?lexikos wrote:These changes may break scripts.
Let's help each other out
https://www.autohotkey.com/boards/
How about a new BIV A_ThisTimer providing all kinds of timers?lexikos wrote:These changes may break scripts.
May is not the correct word. This change will break scripts. I write many of my subroutines to run as a standard subroutines and as timers. Almost all of these routines have SetTimer,,Off as the first line of the subroutine. If this change is implemented as is, I will have to change many many scripts to put back the %A_ThisLabel% or to precede the statement with the "Try" command. AutoHotkey v1.1.01 was released almost 5 years ago. This change can affect thousands if not hundreds of thousands of scripts or more. I sincerely urge you not to break scripts, especially for something that has been this way for almost 5 years.lexikos wrote:Previously (since v1.1.01) the default value of Label was %A_ThisLabel%, even if there is no timer running or there is a timer running but it called a function. Scripts that relied on this weird behaviour will break.
If Label is omitted and the current thread was not started by a timer (or the timer has been deleted), an error is raised.
Built-in variables can only return strings.just me wrote:How about a new BIV A_ThisTimer providing all kinds of timers?
Damn, you're right.jballi wrote:AutoHotkey v1.1.01 was released almost 5 years ago.
That seems likely to be exaggerated.This change can affect thousands if not hundreds of thousands of scripts or more.
Sounds right. I will download the latest version and give it a try/see. Thanks.lexikos wrote:I think it should be sufficient to use A_ThisLabel as before, but falling back to the current timer when A_ThisLabel is empty. Do you see any problems with this? It would mean that a timer callback function wouldn't be able to use SetTimer,,xxx to disable/modify itself from within an internal gosub subroutine/after goto, but that seems like an edge case.
Because they were implemented this way at times when all variables always contained strings?lexikos wrote:Built-in variables can only return strings.just me wrote:How about a new BIV A_ThisTimer providing all kinds of timers?
VarSetCapacity(buf, size * (A_IsUnicode ? 2 : 1), 0) ?Drugwash wrote:And a suggestion that may be useful for many users involved with DllCalls: add a built-in variable called A_CharSize that would hold the value of a character's size according to AHK version (ANSI/Unicode). Would avoid much overhead in functions that require on-the-fly calculation of a struct size, string length and/or other operations.
jNizM wrote:VarSetCapacity(buf, size * (A_IsUnicode ? 2 : 1), 0) ?Drugwash wrote:And a suggestion that may be useful for many users involved with DllCalls: add a built-in variable called A_CharSize that would hold the value of a character's size according to AHK version (ANSI/Unicode). Would avoid much overhead in functions that require on-the-fly calculation of a struct size, string length and/or other operations.
Sure, there are more ways to skin a cat, but why perform on each and every such call an extra calculation (the ternary comparison or anything else) when a single steady variable can readily be available? Waste of time and moreso in functions or subroutines that are being called very frequently (i.e. API wrappers). Personally I see it a bit more than simple convenience. Haven't performed any comparison tests but theoretically there should be some gain, mostly depending on each machine's capabilities.joedf wrote:Yes that's what I usually use.
Code: Select all
;================================================================
updates()
;================================================================
{
Global
w9x := A_OSType="WIN32_NT" ? FALSE : TRUE ; TRUE if system is Windows 95/98/98SE/ME
isBasic := A_AhkVersion < "1.1" ? TRUE : FALSE ; TRUE if AHK version is Basic (not of AHK_L family)
if isBasic
{
Ptr := "UInt" ; Cast pointer type to unsigned integer
UPtr := "UInt" ; Cast unsigned pointer type to unsigned integer
PtrP := "UIntP" ; Cast pointer-to-pointer type to pointer-to-uinteger
UPtrP := "UIntP" ; Cast pointer-to-upointer type to pointer-to-uinteger
AStr := "Str" ; Cast ANSI string type to string
WStr := "UInt" ; Pointer to buffer of Unicode-converted string
i := "A_PtrSize"
if !A_PtrSize
%i% := "4" ; Set pointer size to DWORD (32bit)
}
i := "A_CharSize"
if !iA_CharSize
%i% := 2**(A_IsUnicode=TRUE) ; Character size for use in structures and strings
i := "AW"
if !AW
%i% := A_IsUnicode ? "W" : "A" ; Helper for DllCall() ANSI/Unicode API versions
VarSetCapacity(i, 0) ; Free memory
return TRUE
}
Yes. The differences are described in detail under the "Tab3 vs. Tab2 vs. Tab" heading in the GUI controls documentation.Drugwash wrote:- is Tab3 so different than Tab2 that it demanded its own separate control type instead of updating Tab2?
It could be done. As for how easily, I suppose it depends on the developer. The GUI code hasn't changed significantly, but there have been minor changes throughout the entire project for Unicode and x64 support.- could (only) this Tab change be easily backported to AHK Basic source, should one attempt to improve it?
My apologies, I got a bit rusty. Actually I only wanted to express the joy of having that LV/Background issue fixed so promptly and then got carried away.lexikos wrote:An announcement topic for an obsolete test build is not the right place to request or discuss new features.
Will look at the documentation more thoroughly, thank you.lexikos wrote:The differences are described in detail under the "Tab3 vs. Tab2 vs. Tab" heading in the GUI controls documentation.
Unicode and x64 would be quite too much for now. The most important things I'd like to do in AHK Basic - if possible, if ever - would be synchronizing built-in variables and data types and then maybe a few important fixes/additions such as this Tab3. My C/C++ knowledge is extremely limited and first attempts failed, probably because I bit more than I could chew.lexikos wrote:It could be done. […] The GUI code hasn't changed significantly, but there have been minor changes throughout the entire project for Unicode and x64 support.