AutoHotkey Community

The test function :

The first text code is :
The msgboxes are :
1) This is the text (msgbox of the function)
2) The text is This is the text (msgbox %Try%)
3) OK (msgbox OK)
All is OK,
- I put "this is the text" in a variable (TheText)
- I affect the result of the function to another variable
- I made a test on this variable content.

Next test :
The msgboxes are :
1) This is the text (msgbox of the function)
2) OK (msgbox OK)
All is OK,
- I put "this is the text" in a variable (TheText)
- I made a test using a direct function call

Next test :
The msgboxes are :
1) Nothing is displayed : blank msg (msgbox of the function)
2) OK (msgbox OK)
The result is OK but I am surprised because nothing is displayed in the first msgbox, so the result might be false, but it is OK. I don't know if it's a bug or if it is normal, but the result is OK...
- I made the test using a direct function call in the if statement and I didn't used a temp variable

Next test :
The msgboxes are :
1) Nothing is displayed : blank msg (msgbox of the function)
2) OK (msgbox OK)
The result is the same as before.

Last test :
I have the following error message :


I don't know why the code is (almost) OK with : and with : but not with :

To be honest, the code : give the error message :

IfInString bug ?
Function bug (nothing dispalyed in the message box when I don't do the function call using a variable as parameter) ?
Things to think about them at least, I suppose...

What do you think about that, Chris ?

You can only call functions from the parameters of commands that explicitly allow them. For example, IfInString doesn't support them. You can work around this by specifying "% " (percent sign and space) as the first characters in a non-expression parameter (this can be used in expression parameters too, since it's easy to forget which parameters support functions).

Also, you might already know this but strings passed to a function should be enclosed in quotes. For example: OneFunct("This is the text")

After applying this info, please post again if there is any remaining suspicious behavior. Also, I apologize in advance if I completely missed the point of your post. It's rather long so I didn't scrutinize every detail.

Thanks.

For precsion I made the tests under XP.

I didn't remind that. I tried :and the result was :
I better RTFM and seen :So I tried : and the result was : probably it isn't the right way to do the things. It is of course possible I didn't understood well.

I made other trys all negatives. I wanted to use a direct call to a function in place of the variable to have a more concise writing but I must absolutely pass by an intermediate variable to have a good result.

is not OK
is OK. The use of a variable is an obligation.

So may be it is not bug that don't do the things at all.

Perhaps it can be a wish ?

Thanks for your time, Chris.

Just a guess, but "% expression" can probably only be used as a command parameter that's expected to be a value, not a variable name. In the case of IfInString, the first parameter is expected to be a variable name, i.e. you can't even do
Jacques.

You're absolutely right. I forgot about this when writing the documentation, so it is inaccurate.

I will correct the documentation to indicate that you can't use the "% expression" method for a parameter that is an input or output variable. Thank you both.

Thank you two. But will it be possible (at very low priority level as there are other way to have the same result, to do : so to replace a variable name by a function call, as the result in the twice cases is ... a variable content (and not only in IfInString !!!!!!!!). Probably too much work !!!
Thanks for your explanations.

You can try the InStr() function, which might do what you want.

Thanks but I understood .


At first I thought it may be a bug but I wasn't sure of that.

Now I understand it isn't but I think it would be easier if it was possible to replace, in every command where varaibles are allowed or necessary, to replace them by a call to a function wiitch returns a variable, so to be able to write :in place of :

So ok it isn't any more a bug, it becomes a wish.

I understand it must be an important rewriting of the the code and I think it can't be a high priority, as we can do by an other way, but may be it wuld be a good thing. Thanks for your time.

Thanks for the follow-up.

I'll keep these ideas in mind for a future version even though they might be difficult to do without breaking existing scripts.

Of course don't do that if it break scripts !!! But if it is possible to do that without breaking scripts, it can be a more concise way to write an AHK script.

Thanks for your attention.

Strictly speaking, as currently implemented, functions never return a variable, only a value. I think what you are actually requesting is the following: that commands that currently require an input variable as a parameter (i.e. a parameter the contents of which are used but not modified by the command) be updated to instead accept an expression (such as a function call or an explicit "quoted string") in place of the input variable. This seems like a pretty tall order, though I don't think it breaks existing syntax and therefore would be backward compatible (because a variable name, when treated as an expression, evaluates to the variable's contents, which is all that is required of an input variable -- again, this does not apply to output variables the contents of which are modified by the command).

Note: The only caveat to the backward compatibility claim is the possibility that some valid variable names can be constructed to look like expressions -- the rules for constructing valid variable names have always, it seems to me, been kind of "loose", probably the result of the AutoIt2 heritage where variables were in fact environment variables. For example, A+B (which looks like an expression) is a valid environment variable name and might (I haven't tested this) also be a valid AutoIt2/AutoHotkey variable name. [I apologize if the naming rules have been tightened up at some point while I wasn't looking! ]

Finally, a purely personal comment about this (and similar) requests: in the final analysis, the only benefit of such a feature would be the occasional elimination of the need for an additional line of code (to place an expression result into a temporary variable), at the expense of readability and code simplicity. Note that performance is unlikely to be improved since, internally, AHK still has to evaluate the expression and place the result "somewhere" before continuing with the command, so the extra line of code just makes this step explicit, i.e. you do a tiny amount of extra typing to keep Chris' life simpler! Note that you can decide on a distinctive temporary variable name once and for all (e.g. @T) and keep re-using it in your code every time you need to pre-evaluate an expression, so instead of your you would use and you'd re-use @T every time a similar need arises. I suggest this only because I suspect that sometimes the biggest annoyance in these situations is having to come up with temporary variable names, but since you obviously have no need to use the value again (or you wouldn't be asking for the expression to be able to be incorporated into the command), don't sweat the name!

Later,

Jacques.