Raccoon wrote:
Add Variables A_SecondInstance and A_Reloaded, or A_LoadReason
What would be the possible values of these variables? Btw,
Code:
If InStr(DllCall("GetCommandLine","str"),"/restart")
MsgBox Script was probably restarted.
else
MsgBox Script starting afresh.
I say "probably" because if "/restart" appears after the first unrecognized switch, it is treated as a script parameter. (For AutoHotkey.exe, the first unrecognized switch is used as the filename.) Also, "/R" has the same effect as "/restart".
Quote:
Allow SetTimer to call Functions()
This is something I've wanted for a while, but doesn't come up often. I don't have much idea of how best to implement it, but I haven't looked into the SetTimer code yet.
Quote:
This would allow Timers to be used in #includes, without the Timer Label interrupting the auto-execute section of a script. It would also allow Timers to take advantage of Static variables.
This is already possible:
Quote:
A function may contain externally-called subroutines such as timers, GUI g-labels, and menu items. This is generally done to encapsulate them in a separate file for use with #Include, which prevents them from interfering with the script's auto-execute section. However, the following limitations apply:
- Such subroutines should use only static and global variables (not locals) if their function is ever called normally. This is because a subroutine thread that interrupts a function-call thread (or vice versa) would be able to change the values of local variables seen by the interrupted thread. Furthermore, any time a function returns to its caller, all of its local variables are made blank to free their memory.
- Such subroutines should use only global variables (not static variables) as GUI control variables.
- When a function is entered by a subroutine thread, any references to dynamic variables made by that thread are treated as globals (including commands that create arrays).
Source: Functions As I see it, passing a function to SetTimer would only be of benefit if you could also specify values for the function's parameters. Otherwise I imagine it would be fairly simple to implement.
Quote:
Add GetTimer() Function to check if a Timer exists and get its current state.
Should the return value be similar to the "Period" parameter of SetTimer? Since "Off" is considered true in an expression and 0 is a legitimate period for an enabled timer, an empty string could be used to indicate the timer is disabled.
It would also be feasible to add some indication that the timer's subroutine is running. Would that be useful?
Quote:
Let RegExMatch support the option g)
Would it offer much benefit over
grep()?
A few nights ago I wasted (not spent) several hours trying to determine how one might allow it to return every captured subpattern instead of just the last one. (Such a feature would likely be dependent upon the implementation of "proper" arrays.) Come to think of it, that feature could be adapted to achieve the same effect as g). Anyway, I'm likely to avoid further PCRE-related activities for a good while...
Quote:
I'm not sure why RegExMatch is restricted to the first match. :S
Naturally,
not implementing the "g" option was simpler than implementing it. It isn't difficult to get more matches using a loop, as grep() shows. Here's a simple (possibly inadequate) example:
Code:
h := "grab each word."
n := "\w+"
p := 1
While p := RegExMatch(h, n, m, p) + StrLen(m)
MsgBox % m
I'm open to suggestions, but I'd like to avoid building-in features which are easy to script. The function's you've suggested are perhaps good candidates for a standard library.
However, I think "Str" is a poor choice of name for that function because in my mind it looks like a type-cast and there's no connection to
repeating a string. "Int" also seems like a type-cast, but in that case is appropriate; I'm used to int(n) having the effect you describe, but in another language, where it really is a type-cast.
Max(a,b) and Min(a,b) are very easy to script, but it's not as easy with more parameters. Rather than implementing these functions, I'd like to focus on implementing features that make scripting easier, especially for more advanced tasks. For instance:
Code:
Max(...) {
Loop % A_Params.Count
if A_Params[A_Index] > max
max := A_Params[A_Index]
return max
}
Unfortunately it's much more complicated than it looks. I'm confident of one thing: when I implement it, it won't be pretty.
Of course, the following would be better from a usability perspective:
Code:
Max(...) {
ForEach param in A_Params
if (param > max)
max := param
}
...but I suppose that's even more complicated.
Quote:
You should really come back to the IRC channel.
I disabled my IRC client in an attempt to free up time to actually develop, but instead I've been "wasting" more time on the forums.
Expect to see me idling in #ahk soon.
Login
Register
FAQ
Search
