I just accidentally passed an object to WinText instead of WinTitle, and there wasn't any error.
I've noticed after that some other commands not throwing when passed objects when they are defined in the docs to only expect strings.
Is this expected?
To what extent should commands be expected to throw on wrong type of inputs?
Re: To what extent should commands be expected to throw on wrong type of inputs?
either the documentation is wrong or the implementation is wrong
i see no quoted documentation nor any code posted, so what do u want us to do with this thread?
i see no quoted documentation nor any code posted, so what do u want us to do with this thread?
Re: To what extent should commands be expected to throw on wrong type of inputs?
I didn't have a clear idea if it was wrong or not, so I also didn't know exactly what I wanted myself. I guess I was waiting to see where the conversation lead.
But I could have posted more details.
Here some things that I tried after the first problem:
The original problem itself is quite weird because it started with a bit of an experimentation thing.
It started with ControlClick but I've tried to reduce it and I'm just finding that this thing gives a result that makes sense for some reason...
But I'm misusing things so I didn't quite want to make reference to any of this.
But I could have posted more details.
Here some things that I tried after the first problem:
Code: Select all
WinWait("", {}) ; wrong WinText parameter type but no error
Gui({}) ; wrong Options parameter type but no error
It started with ControlClick but I've tried to reduce it and I'm just finding that this thing gives a result that makes sense for some reason...
Code: Select all
WinA := WinExist("A")
MsgBox WinA "`n`n" WinExist("", {hwnd:WinA}) ; both lines same hwnd
Re: To what extent should commands be expected to throw on wrong type of inputs?
both the documentation and the implementation are wrong. the documentation in the sense that its incomplete, the implementation in the sense that it doesnt complain ure passing garbage values in
in the case of WinWait()(as well as all other WinText, Timeout, ExcludeTitle, ExcludeText]-type functions) all try extracting a string from the optional arguments if possible or use an empty string if not possible, instead of validating the arguments to begin with:
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L1050-L1052
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L1093-L1094
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_func_impl.h#L54-L55
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_func_impl.h#L44-L48
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_func_impl.h#L2
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L16989-L16991
in the case of WinExist():
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L14019
in the case of Gui() constructor
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_gui.cpp#L504
in the case of
knowing what u know now(that any objects u pass in, but shouldnt have, get converted to empty strings) u can explain away why the hwnds are identical:
in the case of WinWait()(as well as all other WinText, Timeout, ExcludeTitle, ExcludeText]-type functions) all try extracting a string from the optional arguments if possible or use an empty string if not possible, instead of validating the arguments to begin with:
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L1050-L1052
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L1093-L1094
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_func_impl.h#L54-L55
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_func_impl.h#L44-L48
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_func_impl.h#L2
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L16989-L16991
in the case of WinExist():
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script2.cpp#L14019
in the case of Gui() constructor
https://github.com/Lexikos/AutoHotkey_L/blob/29fcbf8c63dba0b103a4bb3f62f1c25d67d3a238/source/script_gui.cpp#L504
in the case of
Code: Select all
WinA := WinExist("A")
MsgBox WinA "`n`n" WinExist("", {hwnd:WinA}) ; both lines same hwnd
- WinExist("A") returns the hwnd of the active window and sets the LastFoundWindow to it
- WinExist("", {hwnd:WinA}) which then becomes WinExist("", "") which returns the hwnd of the LastFoundWindow
- both hwnds are the same
Re: To what extent should commands be expected to throw on wrong type of inputs?
Thanks for the detailed explanation. Although I get a general idea I'll be trying to understand it a bit better later.
Relating to the topic I'll wait some days to see if Lexikos says anything here or else I'll try to post a reminder in the bug reports section.
Relating to the topic I'll wait some days to see if Lexikos says anything here or else I'll try to post a reminder in the bug reports section.
Re: To what extent should commands be expected to throw on wrong type of inputs?
To the extent that is documented. If the documentation does not specify any behaviour for a given input, you should withhold any expectations.To what extent should commands be expected to throw on wrong type of inputs?
Validating the type of each parameter currently requires redundant code in each function. In future the functions might be defined with strongly-typed parameters and exposed to script by generating code from metadata (function signatures). In that case, parameter types can be validated as part of the process of conversion, consistently for all functions, and without code duplication.
However, There is no guarantee that WinWait( , obj) will throw even then. Maybe it will call obj.ToString(). This is not yet done for similar reasons to the above.
ValueError: This argument is incorrect.the implementation [is wrong] in the sense that it doesnt complain ure passing garbage values
The caller is wrong to pass garbage values. Although detecting many errors is easy, it is generally impossible to anticipate and detect all errors. There should be no expectation that "garbage values" will be rejected by the function. Garbage can even sometimes coincide with a valid parameter value.
Re: To what extent should commands be expected to throw on wrong type of inputs?
@ Lexikos, Ok, thanks. I had a bit of an intuition about it that's why I didn't post it straightly as a bug. But still wanted to check, also as a way of suggestion if not possible currently.
Re: To what extent should commands be expected to throw on wrong type of inputs?
after reading this i thought i had overlooked something and that ahk did throw an exception(specifically this one), so i went back to check... and it didnt. now im dying laughing over here. good onelexikos wrote: ↑21 Oct 2021, 17:09However, There is no guarantee that WinWait( , obj) will throw even then. Maybe it will call obj.ToString(). This is not yet done for similar reasons to the above.ValueError: This argument is incorrect.the implementation [is wrong] in the sense that it doesnt complain ure passing garbage values
well, the documentation does state that the expected parameter type is "String". it does not say that it would throw if an invalid parameter had been passed in, so if we go along with the "dont have any expectations that things that werent documented would happen" mantra, the documented expected parameter type should be changed to "Whatever you'd like, really"
but i understand v2 is a WIP, so we can let this slide