Click should return "" just like MouseClick

[ZhuangQu]

Code: Select all

MsgBox(Click())
MsgBox(MouseClick())

In the document of Click (https://www.autohotkey.com/docs/v2/lib/Click.htm), there is no return value mentioned.
So Click should return empty string just like MouseClick, not a magic number 5369740240.

[ZhuangQu]

My version is v2.0.12

[ZhuangQu]

I have tested many functions that don't have an return value in the documentation. They all return "", only Click is an magic number.

[boiler]

This is not a bug. There is no behavior here that is counter to the documentation.

So Click should return empty string just like MouseClick, not a magic number 5369740240.

Why should it? The return value is undefined. It is not defined anywhere to be an empty string or anything else. It can be anything or nothing with no consequence to a script that is following the documentation. Since the return value is undefined, then there is no reason for a script to check it or otherwise make use of it. If a script does make use of it and is expecting a certain value, that is an issue with the script, not AHK.

I have tested many functions that don't have a return value in the documentation. They all return "", only Click is a magic number.

That doesn’t matter. Those are also undefined, and you can not and should not count on them returning that value (or lack of value).

[ZhuangQu]

I argue that Click() returns 5369740240 is a bug because of the documentation:

If the flow of execution within a function reaches the function's closing brace prior to encountering a Return, the function ends and returns a blank value (empty string) to its caller. A blank value is also returned whenever the function explicitly omits Return's parameter.

https://www.autohotkey.com/docs/v2/Functions.htm
That means returning an empty string is a default feature of AutoHotkey functions.

[boiler]

You are conflating the documentation of how code written in AHK behaves with the internal behavior of the AHK language itself, which was not written in AHK. And even if it was, you are making an assumption that there is no return value. Again, try to understand the difference between these two concepts: (1) no defined return value, and (2) a return value defined to be blank (or anything else).

I argue that Click() returns 5369740240 is a bug because of the documentation:

The documentation for functions written in AHK have nothing to do with how AHK itself is written. It makes no sense to apply the syntax rules and behavior defined in the documentation for AHK code to the underlying C++ code that the language itself, including the Click() function, was written in. That code needs to be compliant with C++ rules.

That means returning an empty string is a default feature of AutoHotkey functions.

It absolutely does not mean that. You are quoting rules for code written in AHK. Click() is not a function written in AHK, so doesn’t follow AHK’s syntax and therefore doesn’t follow these rules. And there’s nothing that says it doesn’t return a value. Its return value is not defined. It may return a value or maybe it does not, and you as a coder of AHK can make no inferences about whether it does or does or doesn’t, or what its value may be if it does because the return value is not defined.

[joefiesta]

ZhuangQu wrote: ↑
So Click should return empty string just like MouseClick, not a magic number 5369740240.

Boiler replied:
Why should it? The return value is undefined. It is not defined anywhere to be an empty string or anything else. It can be anything or nothing with no consequence to a script that is following the documentation. Since the return value is undefined, then there is no reason for a script to check it or otherwise make use of it. If a script does make use of it and is expecting a certain value, that is an issue with the script, not AHK.

The reply is ridiculous. Essentially, ZhuangQu is saying Click() should NOT RETURN anything (or "" if you look at it that way). That is because, when Click() DOES RETURN something, we have every reason to assume IT WAS FOR A REASON.

Doing something FOR NO REASON is very, very poor coding.

But, if CLICK() is calling an EXTERNAL NON-AHK function that returns a "magic number", then that function is the culprit. Accordingly, that function's documentation should say what was returned and why and, since the average user has no idea wher3e or what that function might be, AHK doc should state the reason.

IT IS A BUG

[Descolada]

@joefiesta I agree with @boiler that this is not a bug. The return values for both MouseClick and Click are undocumented, meaning they can be anything. One shouldn't even rely on MouseClick to return an empty string, because in the future it might be changed to something else: perhaps 1 to signal success, or used CoordMode, or who knows what.
To my knowledge, AHK docs don't say anywhere that built-in functions without an explicit return value must return an empty string, that is just an assumption you've made. And even though functions written in AHK will return empty strings if no return statement is used (which isn't documented to be so for builtin functions), if that function doesn't document a return value then I still wouldn't trust it to return an empty string.

[boiler]

Doing something FOR NO REASON is very, very poor coding.
...
IT IS A BUG

However you may wish to characterize the programming, if it doesn't violate the documented behavior and doesn't cause code that conforms to the documentation to misbehave or crash, it's not a bug. You don't get to make up your own definition of a bug, even if you write it in all-caps.

[joefiesta]

@boiler You made me laugh!!! Really! I liked the "even if youi write it in all caps".

I am just expressing my opinion. I was spoiled as having worked as an IBM MVS and VM mainframe programmer. There, EVERY command has every return code documented. And, the documentation is totally incredibly well organized, precise and in-depth. Don't get me wrong. AHK doc is very good. It's worse flaw is how it is organized and it's syntax conventions, but I'm not going to get on my soapbox about those points.

But, let me ask this: Is there any statement in the v2 doc such as:

A documented function may return a value that is not documented. This undocumented returned value should be considered meaningless

Such a statement I can not find. But, it would make me change me opinion to: THIS IS NOT A BUG.

[boiler]

@boiler You made me laugh!!! Really! I liked the "even if youi write it in all caps".

I am just expressing my opinion.

Yes, we should all feel free do so in a respectful manner.

But, let me ask this: Is there any statement in the v2 doc such as:

A documented function may return a value that is not documented. This undocumented returned value should be considered meaningless

I am not aware of that being stated anywhere, and apparently Descolada, who knows the language more thoroughly than I do, is not either. You might be interested in making a post in Suggestions on Documentation Improvements suggesting such.

By the way, there are other undocumented "features" in AHK, such as map objects being enumerated in alphanumeric order by the keys. While that is the result we currently get, since it is undocumented, we cannot count on it, so the AHK developer has the right to change how that works without it being considered breaking backward compatibility.

[joefiesta]

@Boiler wrote:
so the AHK developer has the right to change how that works without it being considered breaking backward compatibility.

So true!!! I've often imagined just how much in languages and programs is not documented for that very reason. Having programmed--and still doing so as a retired programmer--for over 50 years, I long ago learned the VALUE in documentation. Youngsters need to. Try figuring out a tricky algorithm 10 years after you write it.

As an aside, I'm sadly disappointed that the MANY doc changes I have suggested never got implemented.























2boi

[ZhuangQu]

Thank you for your insightful discussion! I understand.