How about a new BIV A_ThisTimer providing all kinds of timers?lexikos wrote:These changes may break scripts.
Obsolete test build - Tab3 control with autosizing, SetTimer improvements
Re: New test build - Tab3 control with autosizing, SetTimer improvements
Re: New test build - Tab3 control with autosizing, SetTimer improvements
Did I missed something?
[AHK] v2.0.18 | [WIN] 11 Pro (23H2) | [GitHub] Profile
Re: New test build - autosizing Tab3, SetTimer improvements
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.
Them be my thoughts.
Re: New test build - Tab3 control with autosizing, SetTimer improvements
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.
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.
@jNizM: I didn't see this on my Windows 10 system. Thanks for pointing it out (although I had difficulty seeing it even with the red ellipse; a few words of description would have been useful).
Re: New test build - Tab3 control with autosizing, SetTimer improvements
v1.1.22.06-5+gc938422 vs v1.1.23.03-13+gfc20377
The right grey Tab3 "border" line is missing in the latest version.
Windows 10 Enterprise
Version: 1511
Build: 10586.164
The right grey Tab3 "border" line is missing in the latest version.
Windows 10 Enterprise
Version: 1511
Build: 10586.164
[AHK] v2.0.18 | [WIN] 11 Pro (23H2) | [GitHub] Profile
Re: New test build - Tab3 control with autosizing, SetTimer improvements
Yes, I know. You pointed it out in your previous post, and I acknowledged it.
The issue is that the "tab dialog" which hosts the controls is slightly too wide, and is covering the right border. It will be fixed.
The issue is that the "tab dialog" which hosts the controls is slightly too wide, and is covering the right border. It will be fixed.
Re: New test build - Tab3 control with autosizing, SetTimer improvements
v1.1.23.03-17+gf6a2f5e:
- Fixed Tab3 right edge overlapping the border.
- Changed SetTimer,, xxx to use A_ThisLabel as before, but fall back to the current timer when A_ThisLabel is empty.
Re: New test build - Tab3 control with autosizing, SetTimer improvements
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.
Re: New test build - Tab3 control with autosizing, SetTimer improvements
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?
Re: New test build - Tab3 control with autosizing, SetTimer improvements
Yes. The limitation will be removed at some point, but I prefer to not make these sort of changes in the v1 code base. Aside from that, I'd prefer not to add this variable at all since it has, in my opinion, limited usefulness.
The point of SetTimer's Label being optional is merely convenience. If you have any practical need to identify the current timer from a function which serves multiple timers, you can use Bind or a class with a Call method (patterns which will also work with any other callbacks, like Gui, menu, OnMessage, etc).
The point of SetTimer's Label being optional is merely convenience. If you have any practical need to identify the current timer from a function which serves multiple timers, you can use Bind or a class with a Call method (patterns which will also work with any other callbacks, like Gui, menu, OnMessage, etc).
Re: New test build - Tab3 control with autosizing, SetTimer improvements
Hey lexikos,
some new updates about your motivation to integrate Tab3 into main release?
Im still on v1.1.23.03-17+gf6a2f5e
some new updates about your motivation to integrate Tab3 into main release?
Im still on v1.1.23.03-17+gf6a2f5e
[AHK] v2.0.18 | [WIN] 11 Pro (23H2) | [GitHub] Profile
Re: New test build - Tab3 control with autosizing, SetTimer improvements
v1.1.24.00 integrates this branch.
Re: New test build - Tab3 control with autosizing, SetTimer improvements
I've wasted the whole day today unaware of the lonstanding issue in Tab regarding BackgroundTrans and ListView. Had I known about v1.1.24.00 earlier…
Anyway, fixing controls' background color in a themed Tab is most welcome, thank you!
I'd have two questions (one may have already been asked, haven't read this whole topic ):
- is Tab3 so different than Tab2 that it demanded its own separate control type instead of updating Tab2?
- could (only) this Tab change be easily backported to AHK Basic source, should one attempt to improve it?
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.
I would stretch the above request to another built-in variable called simply AW that would additionally avoid calculation overhead when choosing API versions based on AHK ANSI/Unicode version (such as DllCall("FormatMessage" AW […] vs DllCall("FormatMessage" (A_IsUnicode ? "W" : "A") […] ).
They would both improve code readability and - more important - script speed, especially when such functions are called repeatedly and/or execution time is critical.
Anyway, fixing controls' background color in a themed Tab is most welcome, thank you!
I'd have two questions (one may have already been asked, haven't read this whole topic ):
- is Tab3 so different than Tab2 that it demanded its own separate control type instead of updating Tab2?
- could (only) this Tab change be easily backported to AHK Basic source, should one attempt to improve it?
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.
I would stretch the above request to another built-in variable called simply AW that would additionally avoid calculation overhead when choosing API versions based on AHK ANSI/Unicode version (such as DllCall("FormatMessage" AW […] vs DllCall("FormatMessage" (A_IsUnicode ? "W" : "A") […] ).
They would both improve code readability and - more important - script speed, especially when such functions are called repeatedly and/or execution time is critical.
Part of my AHK work can be found here.
Re: New test build - Tab3 control with autosizing, SetTimer improvements
Tab vs Tab2 vs Tab3
A_CharSize would be nice
A_CharSize would be nice
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: New test build - Tab3 control with autosizing, SetTimer improvements
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.
[AHK] v2.0.18 | [WIN] 11 Pro (23H2) | [GitHub] Profile
Re: New test build - Tab3 control with autosizing, SetTimer improvements
Yes that's what I usually use.
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: New test build - Tab3 control with autosizing, SetTimer improvements
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.
In my scripts I've been using the global variable AW (together with others, see below) in a compact script #included at the beginning of the autoexec section which allows a better compatibility when same scripts are being run under AHK Basic and AHK 1.1+ (I'm still using Win98SE as my main machine and developing scripts on it, in case someone is wondering). Very recently I've changed the logic a bit, making the extra script a function and putting it in the lib folder; on that occasion it occured to me the creation of the A_CharSize variable which I then included into the function. It would be nice (and consistent) if AHK 1.1+ would sport those two variables by default so that anybody running my scripts on their machines under AHK 1.1+ would not even require the presence of the extra script. Better compatibility.
Oh well, that's it. Here's my extra script:
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
}
Part of my AHK work can be found here.
Re: New test build - Tab3 control with autosizing, SetTimer improvements
An announcement topic for an obsolete test build is not the right place to request or discuss new features.
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?
Re: New test build - Tab3 control with autosizing, SetTimer improvements
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.
Talking about Tab3, after a prolonged testing I've noticed a visible flickering of the controls belonging to an inactive tab through the surface of the active tab. There is a ListView in one of the inactive tabs. AHK v1.1.24.0, Windows XP Pro SP4, Intel P4 1.8GHz, 576MB RAM, GeForce 5700. I wonder if anyone else noticed that.
Should I open a new topic in Bugs & Feature requests in regard to the suggested variables above?
Part of my AHK work can be found here.
Who is online
Users browsing this forum: No registered users and 10 guests