Improve InStr or IfInString

Propose new features and changes
dsewq1LYJ
Posts: 113
Joined: 26 Aug 2014, 23:21

Improve InStr or IfInString

16 May 2017, 06:45

Code: Select all

WinGetTitle,T,ahk_id %wID%
if InStr(T,"Add")
|| InStr(T,"Install")
|| InStr(T,"Launch")
|| InStr(T,"License")
|| InStr(T,"Setup")
|| InStr(T,"Vim")
{}
It looks not nice (I'm not talking about readabilitiy, i'm talking about performance),
but this one is much faster than RegExMatch().

Code: Select all

WinGetTitle,T,ahk_id %wID%
if RegExMatch(T,"(Add|Install|Launch|License|Setup|Vim)")
{}
This one<RegExMatch()> is extreme slow compare with previous one<InStr()>.
and also the previous one is not smart (IMO)...if the String is always T then you just need to move the pointer from the begin to the tail once <Walk (or Iterate ) through the String once>.

~ I haven't read the source of AHK so, hope I'm not giving stupid suggestion.

Pseudo-code

Code: Select all

WinGetTitle,T,ahk_id %wID%
if InStrGrp(T,"\Add|Install|Launch|License|Setup|Vim/", IsCaseSensitive, ...)
{}
; Add | Install | Launch | License | Setup | Vim
if InStrGrp(T,"\Add \Ruby|Python|PHP|Java/|\Install|Setup/ \eclipse|PyCharm|MVS//", ...)
{}
; Add Ruby | Add Python | Add PHP | Add Java , Install eclipse | Setup eclipse | Install PyCharm | Setup PyCharm | Install MVS | Setup MVS
I knew it's just regex-like code and another function name, but hope someone can tell me why RegExMatch can being so slow in 1 million calls comparison.

First case <InStr>
1,000,000 calls took 1.524463 sec <Match last InStr() condition>
1,000,000 calls took 1.248547 sec <Match first InStr() condition>

Second case <RegExMatch>
1,000,000 calls took 2.469198 sec
User avatar
nnnik
Posts: 3351
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Improve InStr or IfInString

16 May 2017, 08:09

You can increase the speed of RegExMatch with the study option
Recommends AHK Studio
Helgef
Posts: 3195
Joined: 17 Jul 2016, 01:02
Contact:

Re: Improve InStr or IfInString

16 May 2017, 10:19

I'm not sure that the study option is relevant in the case of a single call,
Study wrote:This is useful when a particular pattern (especially a complex one) will be executed many times.
Removing the (), might give a slight improvement for the regex.

However, I don't see how the speed difference would ever matter in the context of working with windows. Do you really need to do a million checks?

Cheers.
guest3456
Posts: 2419
Joined: 09 Oct 2013, 10:31

Re: Improve InStr or IfInString

16 May 2017, 10:21

just write your own InStrGrp() wrapper?

User avatar
jeeswg
Posts: 5151
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Improve InStr or IfInString

16 May 2017, 10:29

Other than StrContains/StrIn/StrStarts/StrEnds functions...

I think an all-in-one StrMatch function could be a good idea.

This syntax is not set in stone, but demonstrates the principle:

Code: Select all

StrMatch(options, needle, haystack)
StrMatch(options, needle, haystack1, haystack2, haystack3, ...)
StrMatch("", "a", "a") ;function is case insensitive by default
StrMatch("D,", "a", "a,b,c") ;var matches one of list
StrMatch("", "a", "a", "b", "c") ;var matches one of list
StrMatch("c D,", "a", "a,b,c") ;var contains one of list
StrMatch("c a D,", "abc", "a,b,c") ;var contains all items in list
StrMatch("e a", "abc", "a", "b", "c") ;var ends with one of list
Options could include:
- case sensitive/case insensitive
- delimiter/omit characters (cf. Loop)
- var contains/matches/starts/ends (cf. SetTitleMatchMode)
- var contains all items in list
- return value: index of first match/match count

Link:
Creating a user defined function to search in an Array - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 37&t=30571

Note: Lots of people seem to be having this issue:
Check multiple vars against single value - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=31530

Note: This proposal fits with StrReplace being needed as a faster alternative to RegExReplace for common situations, that avoids issues relating to escape characters.

@Helgef, quite often I'll check massive lists against a small lists (sometimes against massive lists).

In my opinion, it's stupid for people to need a custom function for this or for new users to be wasting any more time on the forums having to make requests for or discuss this trivial issue.

@dsewq1LYJ, many thanks for your post.

[EDIT:] With 'if var in/contains' due to be removed, and having limitations anyway (regarding specifying delimiters and case, and lacking a return value, and support for use with && and || like a normal function would) this issue needs proper consideration.
Last edited by jeeswg on 16 May 2017, 12:28, edited 2 times in total.
guest3456
Posts: 2419
Joined: 09 Oct 2013, 10:31

Re: Improve InStr or IfInString

16 May 2017, 11:49

guest3456 wrote:just write your own InStrGrp() wrapper?

Code: Select all

title := "Notepad"
MsgBox, % InStrGrp(title, "Add|Install|Launch|License|Setup|Vim")
title := "Launch"
MsgBox, % InStrGrp(title, "Add|Install|Launch|License|Setup|Vim")
return

InStrGrp(haystack, needle)
{
   needles := StrSplit(needle, "|")
   Loop, % needles.Length()
      if InStr(haystack, needles[A_Index])
         return true
   return false
}



User avatar
Flipeador
Posts: 1018
Joined: 15 Nov 2014, 21:31
GitHub: Flipeador
Location: Argentina
Contact:

Re: Improve InStr or IfInString

17 May 2017, 13:44

You may find this useful:
User avatar
jeeswg
Posts: 5151
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Improve InStr or IfInString

16 Dec 2017, 04:28

How about letting InStr accept an array.
[EDIT:] Or better, a generalised StrMatch super-function, with separate StrContains/StrExact functions for convenience.
[EDIT:] The Options parameter would be case insensitive, but capital letters would be recommended.

And replacing the case insensitive parameter with an options parameter.

;C/X/S/E (contains/exact match/starts/ends) (contains is default)
;D (no delimiter, individual characters)
;D, (delimiter: comma)
;CS/CI/CL (case sensitive/case insensitive/case insensitive locale)
;N (numeric comparison)
;< <= > >= (check for special kinds of matches)
;T (return count of matching items) [EDIT: may instead be force text comparison][perhaps RC instead]
;F (return index of first matching item) [perhaps RF instead]
;L (return position of leftmost of all matches, rather than position of first match) [perhaps RL instead]
;A (contains all)
;[EDIT:] R (RegExMatch)
;[EDIT:] W (within, opposite of 'contains') (if a within abc, if abc contains a)

Code: Select all

;before and after:
InStr(vText, vNeedle, vCaseSen, vPos, vOcc)
InStr(vText, vNeedle/oNeedle, vOpt, vPos, vOcc) ;if contains
StrMatch(vText, vNeedle/oNeedle, vOpt) ;if in (default)/contains/starts/ends etc

vText := "a"
vList := "a,b,c"
oList := ["a","b","c"]

if StrMatch(vText, vList, "D,") ;if in (exact match)
if StrMatch(vText, vList, "C D,") ;if contains

if StrMatch(vText, oList) ;if in (exact match)
if StrMatch(vText, oList, "X") ;if in (exact match) (X is unnecessary)
if StrMatch(vText, oList, "C") ;if contains
if StrMatch(vText, oList, "C A") ;if contains all
if !StrMatch(vText, oList, "C") ;if contains none
if StrMatch(vText, oList, "S") ;if starts
if StrMatch(vText, oList, "E") ;if ends

if StrMatch(vText, oList) ;if in (exact match)
if StrMatch(vText, oList, "C") ;if contains
if StrExact(vText, oList) ;if in (exact match)
if StrContains(vText, oList) ;if contains
if InStr(vText, oList) ;if contains
Good things can happen when you allow parameters to accept arrays.

A similar change to StrReplace to allow multiple and case insensitive replacements.

;D (no delimiter, individual characters)
;D, (delimiter: comma)
;CS/CI/CL (case sensitive/case insensitive/case insensitive locale)
;L1 (limit 1)

Code: Select all

;before and after:
StrReplace(vText, vNeedle, vReplaceText, vCount, vLimit)
StrReplace(vText, vNeedle, vReplaceText/oReplaceText, vCount, vOpt)

vText := "a"
vList := "a,b,c"
oList := ["a","b","c"]

;replace list
vText := StrReplace(vText, vList, "", "", "D,")
vText := StrReplace(vText, oList)

;replace list (individual characters)
vText := StrReplace(vText, "abc", "", "", "D")

;replace case sensitive
vText := StrReplace(vText, vNeedle, vReplaceText, "", "CS")
Similarly, the Run command could accept an array.

Code: Select all

Run(["notepad.exe", "MyFile.txt"])
Run("""notepad.exe"" ""MyFile.txt""")
- when function met array -
Last edited by jeeswg on 24 Feb 2018, 02:41, edited 9 times in total.
User avatar
nnnik
Posts: 3351
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Improve InStr or IfInString

16 Dec 2017, 04:59

jeeswg wrote:How about letting InStr accept an array.

And replacing the case insensitive parameter with an options parameter.

;c/x/s/e (contains/exact match/starts/ends) (contains is default)
;d (no delimiter, individual characters)
;d, (delimiter: comma)
;cs/ci (case sensitive/case insensitive)
;n (numeric comparison)
;< <= > >= (check for special kinds of matches)
;t (return count of matching items)
;f (return index of first matching item)
;L (return position of leftmost of all matches, rather than position of first match)
;a (contains all)

Code: Select all

;before and after:
InStr(vText, vNeedle, vCaseSen, vPos, vOcc)
InStr(vText, vNeedle/oNeedle, vOpt, vPos, vOcc)

vText := "a"
vList := "a,b,c"
oList := ["a","b","c"]

if InStr(vText, vList, "x d,") ;if in (exact match)
if InStr(vText, vList, "d,") ;if contains

if InStr(vText, oList, "x") ;if in (exact match)
if InStr(vText, oList) ;if contains

if InStr(vText, oList, "a") ;if contains all
if !InStr(vText, oList) ;if contains none
if InStr(vText, oList, "s") ;if starts
if InStr(vText, oList, "e") ;if ends
A horrible idea.
Options in that style are cancerous and should never be used in any sort of function - instead you should write a different function that does exactly that instead.
e.g. ( CountInStr( ) ;counts the number of occurencies of a specific element inside text )
Here are the advantages of doing that:
  • Easier to read
  • Faster
  • Less error prone
  • You loose no power since you could use function objects and arrays when you need to make function calls dynamic
  • Easier to remember
Recommends AHK Studio
User avatar
jeeswg
Posts: 5151
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Improve InStr or IfInString

16 Dec 2017, 05:25

A horrible idea.
Options in that style are cancerous and should never be used in any sort of function - instead you should write a different function that does exactly that instead.
- That is quite a surprising and borderline extreme reaction.
- AutoHotkey already allows parameters in this style, e.g. Sort, they are quite good for situations where you have various miscellaneous options.
- Although, maybe you don't like when AutoHotkey does this, in which case, I would be interested to hear of any such AHK functions/commands that do this, and whether you don't like/don't mind that they do this. How would you rewrite Sort or Click/MouseClick or the Gui command?
e.g. ( CountInStr( ) ;counts the number of occurencies of a specific element inside text )
I had suggested a StrCount function, my InStr proposal here doesn't do this (although StrReplace can already do this).
- The InStr proposal does something different, it tells you how many, of multiple needles, a haystack contains.
•Easier to read
...
•Less error prone
•Easier to remember
- The function would still have the same parameter functionality and order, and a small number of parameters. It all seems fairly simple.
•Faster
- Flipeador started a similar debate re. NumGet/NumPut and speed. I'm sympathetic to arguments regarding speed. Would it really be an issue, or is this just theoretical?
•You loose no power since you could use function objects and arrays when you need to make function calls dynamic
- Apologies, not really sure what you were trying to say here.

I have felt the need for a general, all-purpose string matching/comparison function, that you can copy and paste and tweak for different scenarios. Additionally, something like this could be useful, for doing things within parentheses.
if (a contains b, options)
User avatar
nnnik
Posts: 3351
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Improve InStr or IfInString

16 Dec 2017, 05:57

jeeswg wrote:
A horrible idea.
Options in that style are cancerous and should never be used in any sort of function - instead you should write a different function that does exactly that instead.
- That is quite a surprising and borderline extreme reaction.
- AutoHotkey already allows parameters in this style, e.g. Sort, they are quite good for situations where you have various miscellaneous options.
- Although, maybe you don't like when AutoHotkey does this, in which case, I would be interested to hear of any such AHK functions/commands that do this, and whether you don't like/don't mind that they do this. How would you rewrite Sort or Click/MouseClick or the Gui command?
Those are not functions.
•Easier to read
...
•Less error prone
•Easier to remember
- The function would still have the same parameter functionality and order, and a small number of parameters. It all seems fairly simple.
Yeah so what? It's simple but less readeabled more error prone, more difficult to remember...
•Faster
- Flipeador started a similar debate re. NumGet/NumPut and speed. I'm sympathetic to arguments regarding speed. Would it really be an issue, or is this just theoretical?
[/quote]It is marginably slower. But the point is not a major point. It's just to show you that your suggestion is absolutely pointless.
I have felt the need for a general, all-purpose string matching/comparison function, that you can copy and paste and tweak for different scenarios. Additionally, something like this could be useful, for doing things within parentheses.
if (a contains b, options)
Why? Why does it have to be one function? Also that operator syntax breaks everything operators stand for in programming - it's better if you forget that idea.
Recommends AHK Studio
User avatar
jeeswg
Posts: 5151
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Improve InStr or IfInString

16 Dec 2017, 06:45

Those are not functions.
- Well, (a) they will be functions, (b) do you object to that style of parameters in commands? And (c), both of those points will have occurred to you. I don't think the position that space-separated letters being bad for parameters is at all self-evident, it cannot stand without supporting arguments, what possible better alternative could you have.
less readeabled more error prone, more difficult to remember
- The parameter order/meanings remain the same. The syntax using obvious letters is easy to remember. Readability/errors is not particularly an issue, especially if you use variable/object names instead of hardcoded text. Even if you use hardcoded text, it's not so bad.
that operator syntax breaks everything operators stand for
- You're right here, that comma suggestion, I believe I saw that somewhere else. However what you could do, if you wanted a possible second parameter, is this:
if a contains b
if a contains (b, options)
suggestion is absolutely pointless
...
Why does it have to be one function?
- The idea of an all-purpose string match/compare function has a great deal of value, separate functions would also have value. A key gain here is convenience.

E.g. I very much dislike moving between: InStr, =, RegExMatch, ~=, custom functions, contains, in. Plus none of the standard functionality lets you change the delimiter (e.g. from comma to pipe), plus methods vary for specifying case sensitive/case insensitive. Plus it's not always so easy to specify numeric or less than/greater than comparisons. While some of this functionality exists in AHK, key things are missing, and I don't want to include a massive all-purpose string function, or ugly/bespoke workaround, every time I share a script on the forum.

Code: Select all

if InStr(vText, vNeedle)
if (vText = vNeedle)
if (vText == vNeedle)
if RegExMatch(vText, vNeedle)
if (vText ~= vNeedle)
if MyFunc(vText, vNeedle)
if vText in % vNeedles
if vText contains % vNeedles
I would like functions with a similar parameter order, or one all-purpose function, or operators for all common comparisons (with an options parameter). So that I can just switch the operator, switch a parameter, or switch the function name. It's currently one of the biggest time-stealers when I program in AHK.

Code: Select all

;current operators/current functions that I use:
(t = n)		JEE_StrMatch
(t == n)	JEE_StrMatch
(t > n) ;string	JEE_StrMatch
(t < n)	;string	JEE_StrMatch
(t > n) ;num	JEE_StrMatch
(t < n)	;num	JEE_StrMatch
(t ~= n)	RegExMatch

;proposed operators/current functions that I use:
(t contains n)	InStr (for one item)
(t contains n)	JEE_StrMatch / JEE_MC
(t in n)	JEE_StrMatch / JEE_MX
(t starts n)	JEE_StrMatch [or: (t contains (n, "s"))]
(t ends n)	JEE_StrMatch [or: (t contains (n, "e"))]

;new idea:
(t operator n)	InStr (updated)
(t operator (n, options))	InStr (updated)
User avatar
nnnik
Posts: 3351
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Improve InStr or IfInString

16 Dec 2017, 07:04

I don't want to waste my time replying to you.
You're wrong on several aspects and I don't have the time to teach you everything.
Either learn some more before trying to argument or simply leave it be.
Recommends AHK Studio
User avatar
jeeswg
Posts: 5151
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Improve InStr or IfInString

16 Dec 2017, 07:42

- @nnnik: In the past, I gave you and one or two other long-term contributors to the forum, the benefit of the doubt.
- But now, insisting that unsubstantiated statements are correct, won't cut it.
- I thought very carefully about these proposals, as I do for all proposals. *Very* carefully. People are welcome to posit legitimate criticisms of the proposals.
User avatar
nnnik
Posts: 3351
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Improve InStr or IfInString

16 Dec 2017, 08:49

Yes but you miss some details due to your lack of experience, like:
GUI will turn into an object which is once again not a function.
Editors will auto complete a function but it won't auto fill any parameters. Words are easier to remember than single letters especially when it comes to meaning. How exactly do you plan to make these variables that make things more readable available to all scopes where you use inStr? Super-Globals? Do you even understand a single bit of the problems caused by super globals?

What's essential when it comes to designing any kind of language is knowledge about multiple languages - the more the better. Yet you seem to try to design this language without even extended experience in all sorts of development styles in AHK.
Recommends AHK Studio
User avatar
jeeswg
Posts: 5151
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Improve InStr or IfInString

16 Dec 2017, 09:28

- Thanks for your response.
- So you don't like letters in parameters for commands/functions/object methods, you prefer words. (Btw, re. functions: AHK typically provides function versions of object methods, and object methods are functions defined inside/outside of classes.)
- In my view, words are too long/unnecessarily long. 'Seconds' or 'S' in the DateAdd function, 'S' seems clear enough. I like 'FDR', for 'files, directories, recurse' just fine, I don't want to write them in full. What would RegEx be with 'multiline' instead of 'm'?
- I'm not sure what you thought the variable issues was. I don't see a problem with putting a variable/array into a function as per usual. You mentioned readability as an argument, and I was saying this, about using variables to aid readability:

Code: Select all

;easier to read perhaps
oNeedles := ["a","b","c"]
vPos := InStr(vText, oNeedles, "x")

;harder to read perhaps
vPos := InStr(vText, ["a","b","c"], "x")

;easier to read perhaps
vNeedles := "a,b,c"
vPos := InStr(vText, vNeedles, "x D,")

;harder to read perhaps
vPos := InStr(vText, "a,b,c", "x D,")
- I don't see a problem with autocomplete. Editors can't read your mind to know what you want to put. Or I didn't understand the point you made.
- I don't feel that I'm designing the language, I'm simply proposing a standard function with standard parameters. Clearly, up till now, apart from StrSplit, not much use has been made of arrays in standard functions.
- I expected that people might say something like 'hey, arrays in StrReplace, to do multiple replaces, nice'. Or 'I don't really like that letter for that functionality in the options parameter'. You basically said the whole InStr suggestion was very bad, when all it is is a minor tweak to the existing function.
- One thing I have since noticed is that 'D' rather than 'd' for delimiter is clearer, although both would be acceptable to use, since the options parameter letters would be case insensitive.
Last edited by jeeswg on 16 Dec 2017, 09:31, edited 1 time in total.
User avatar
nnnik
Posts: 3351
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Improve InStr or IfInString

16 Dec 2017, 09:38

No I don't prefer words.
Re:Object's and functions: you don't understand anything about Object's. If you can't even see the conceptual difference between functions and methods.
So you want me to add variables to every function that I use inStr in?
AutoComplete will complete CountInStr() but not inStr(.."c").
I'm actually perfectly fine with arrays in inStr.
Recommends AHK Studio
User avatar
jeeswg
Posts: 5151
Joined: 19 Dec 2016, 01:58
Location: UK

Re: Improve InStr or IfInString

16 Dec 2017, 10:44

Words are easier to remember than single letters especially when it comes to meaning.
...
No I don't prefer words.
...
AutoComplete will complete CountInStr() but not inStr(.."c").
- OK, you see, sometimes you leave things out, and then people don't understand you.
- I believe that what you meant is that function names are better than letter parameters, because the function name says what it does, and that you can use autocomplete with function names, but not with parameter letters.
- These are good arguments, I wish you'd expressed it like that.
- I don't use autocomplete, I do use hotstrings, and my proposal would work great with hotstrings. Generally, I think that hotstrings are better than autocomplete.
- The benefit of my idea also is that it's easier to modify one parameter, than to overwrite a function name.
Re:Object's and functions: you don't understand anything about Object's. If you can't even see the conceptual difference between functions and methods.
- When you said earlier that commands (that will be functions in AHK v2) are not functions, was that helpful?
- Are not commands/functions/methods/bound funcs/func objects, similar and related? If someone was incapable of seeing *that*, wouldn't that be the bigger problem? Luckily, both of us understand both concepts.
So you want me to add variables to every function that I use inStr in?
- *You* said that the function might have readability issues, I don't think it would. Actually, there are a small minority of functions that it is difficult to make the perfect syntax for.
- Adding multiple new functions to AHK, seems like a harder sell than extending the functionality of an existing one. Also, being able to always use InStr, and not having to overwrite the function name, is an advantage.
- My proposal is about as good as you can make it. But I post things partly to get other perspectives/ideas.
Helgef
Posts: 3195
Joined: 17 Jul 2016, 01:02
Contact:

Re: Improve InStr or IfInString

16 Dec 2017, 15:06

jeeswg wrote:- My proposal is about as good as you can make it.
I love your confidence ;) , but I'm not very fond of the idea of making a simple core function like instr much more complex, and I'm not loving the string options. I'd rather see a few more simple core functions. I think allowing the needle to be an array of needles would be ok, maybe even nice, but you would need to return {pos:pos, index:index}, that is the position of the match and the index of the matching string in the needle array.

Core functions like instr are meant to be used like guest3456 suggested with the InStrGrp(haystack, needle) function, you build a function for your special cases with them and performance will not be an issue in most cases.

Your suggestion would be more fit as completely new function.

:offtopic:
Spoiler
Cheers.
User avatar
nnnik
Posts: 3351
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Improve InStr or IfInString

16 Dec 2017, 15:14

- OK, you see, sometimes you leave things out, and then people don't understand you.
- I believe that what you meant is that function names are better than letter parameters, because the function name says what it does, and that you can use autocomplete with function names, but not with parameter letters.
- These are good arguments, I wish you'd expressed it like that.
- I don't use autocomplete, I do use hotstrings, and my proposal would work great with hotstrings. Generally, I think that hotstrings are better than autocomplete.
- The benefit of my idea also is that it's easier to modify one parameter, than to overwrite a function name.
Most common tools of editing support auto complete. It is a common concept thats used across almost every programming language.
On the other hand we have your special unique hotstring script. Guess what's more important.
I leave things out I consider common sense and I know to be common sense among developers. You are not a full fledged programmer yet, so you have problems understanding it.
- Are not commands/functions/methods/bound funcs/func objects, similar and related? If someone was incapable of seeing *that*, wouldn't that be the bigger problem? Luckily, both of us understand both concepts.
Of course on a macro layer there is the command and the function syntax. But on a micro layer all these programm elements are different and are used for different things.
You don't understand this micro layer. Of course it would be worse if someone doesn't even understand the macro layer. But that doesn't mean that not understanding the micro layer is that much better.
*You* said that the function might have readability issues, I don't think it would.
Well I think it would - you fail to provide any argument here. A word in front of the function name is more difficult to miss than a single seperate letter at the end.
- Adding multiple new functions to AHK, seems like a harder sell than extending the functionality of an existing one.
I don't know if the source code makes it easier for that, other than that I don't see any hindrance to do that.
Also, being able to always use InStr, and not having to overwrite the function name, is an advantage.
Thats just your preference
- My proposal is about as good as you can make it. But I post things partly to get other perspectives/ideas.
You can always make things better.

Gaining a different perspective is mostly done to learning. Explaining and argumenting about a different perspective is essentially teaching another person your perspective therefore what you have learned.
In something so theoretical as programming argumenting with something that has learned a lot less than you did is essentially pointless, unless you like teaching people.
However it's unrewarding to teach you everything if you basically choose to reject it every time you don't like something and request a reasoning that you can understand.
You should really learn another language or learn AHK completely before you make suggestions like these.
Recommends AHK Studio

Return to “Wish List”

Who is online

Users browsing this forum: No registered users and 3 guests