OnEvent Error

[iPhilip]

The example code below yields the following error under the latest v2.0-alpha release (2.0-a103-56441b52) when closing the Gui:

Code: Select all

Error:  Too many parameters passed to function.

Here is the code:

Code: Select all

myGui := GuiCreate()
myGui.AddText("", "Press Alt+F4 or the X button in the title bar.")
myGui.OnEvent("Close", "myGui_Close")
myGui.Show

myGui_Close() {
    ExitApp
}

Replacing

Code: Select all

myGui_Close() {

with

Code: Select all

myGui_Close(thisGui) {

eliminates the error. According to the documentation declaring that parameter is optional.

[lexikos]

The documentation is incorrect (outdated).

[iPhilip]

@lexikos, Thank you. The code below produces the same error. Could you point out what I am doing wrong?

Code: Select all

myGui := GuiCreate()
myGui.AddText("", "Press Alt+F4 or the X button in the title bar.")
myGui.OnEvent("Close", () => ExitApp())
myGui.Show

[nnnik]

The OnEvent method expects a function that can accept a specific amount of parameters.
You are handing it a function that doesn't accept any.
You need to make sure it can hold at least that much.

As a shorthand you could use:

Code: Select all

myGui := GuiCreate()
myGui.AddText("", "Press Alt+F4 or the X button in the title bar.")
myGui.OnEvent("Close", (*) => ExitApp()) ;* to accept but ignore any surplus parameters
myGui.Show

See:
https://www.autohotkey.com/boards/viewtopic.php?p=276644#p276644

Changed function calls to throw if too many parameters are passed.
Added fn(a,*) as a means to permit but not store surplus parameters.
[...]

[iPhilip]

The OnEvent method expects a function that can accept a specific amount of parameters.
You are handing it a function that doesn't accept any.
You need to make sure it can hold at least that much.

@nnnik, Thank you for pointing that out. That was not the case in the previous version. (I verified it with AHK v2.0-a100-52515e2.) While I think it will cause unnecessary confusion (I first saw it implemented in this post), I am sure there are good reasons for it being that way. In any case, it seems to me that the error should read

Too manyfew parameters passed to function.

since no parameters generates the error.

As a shorthand you could use:

Code: Select all

myGui := GuiCreate()
myGui.AddText("", "Press Alt+F4 or the X button in the title bar.")
myGui.OnEvent("Close", (*) => ExitApp()) ;* to accept but ignore any surplus parameters
myGui.Show

See:
https://www.autohotkey.com/boards/viewtopic.php?p=276644#p276644

Changed function calls to throw if too many parameters are passed.
Added fn(a,*) as a means to permit but not store surplus parameters.
[...]

Thank you. I appreciate your help.

[lexikos]

That was not the case in the previous version.

Of course it wasn't. That is why it was written in the change log (in the announcement post), which nnnik quoted. It is very important to read the change log before downloading a new alpha release. Every new release of any kind always includes something that was not the case in the previous version, and v2 alpha releases are not intended to be backward-compatible.

Too manyfew parameters passed to function.

No, you are confusing "passed to" with "defined by". The GUI itself passes parameters too many parameters to your function, which defines too few parameters. The exception is thrown when the function is called, at which point there's no way to make the distinction. There's just a function, and a list of parameters being passed.

At some point I will revise the error handling code to permit more informative error messages without bloating the code. For instance, "Function {name} requires between {min} and {max} parameters, but was called with {actual}."


After encountering this in my own scripts, I considered allowing => expr as short-hand for (*) => expr. Often the parameters aren't needed because the values are already available in the enclosing scope. If the function should strictly require 0 parameters, it can be written as () => expr.

[kczx3]

That’s unfortunate. Seems silly just to have to remember to type the asterisk as a means to throw away parameters.

[Helgef]

I disagree, it helps avoid errors and shows intent. Perhaps the () must not be required, but the * should, for fat arrow that is.

Cheers.

[kczx3]

How would it reduce errors?

[swagfag]

do u not consider passing an incorrect number of parameters an error?
u couldnt do it for normal functions and now u cant do it for callables anymore(whereas u previously could)

https://www.autohotkey.com/boards/viewtopic.php?f=37&t=64310
i get that its annoying having to go back and change scripts that used to rely on this inconsistency, but i think ahk is ultimately better for it

[Helgef]

How would it reduce errors?

Just one example, %f%(obj,prop) when you meant %f%(obj.prop) where f.maxparams == 1 (and f isn't variadic).

Cheers.

[kczx3]

I still don’t see how that matters when I simply want to call a function and don’t care about what is passed in. This seems like a loss in flexibility

[swagfag]

well, technically, if u wanted to "simply call a function and not care about what was passed in", u had to have defined a variadic sink as the function's last argument.
u didnt have to do this for callbacks, function references and the like. now u do
does it make sense these two to behave differently:

Code: Select all

greet() {
	MsgBox 'hello'
}

greet('garbage', 'goes', 'in') ; throws

fn := Func('greet')
%fn%('garbage', 'goes', 'in') ; this is ok, though

i get that its convenient/flexible as u put it when it comes to working with guis, but i have to question the degree to which having to punch out an additional asterisk impairs this supposed flexibility
at the end of the day its gonna be a trade-off between flexibility/convenience and consistency/correctness

idk what to make of @lexikos's considerations of allowing => expr. this seems like its introducing just another special case. whats the equivalent if the handler was a normal function? there isnt any, ud have to write *. if the parser can be made to handle * => expr as @Helgef suggests, without any ambiguities, i think this could be acceptable, since arg1 => expr is a thing already.
or maybe the gui system can be changed to only pass in as many parameters as the handler defines and keep the pre-103 syntax, but will yet again end up being just another special case and it will only work for the gui system and not any user-defined stuff
or maybe the pendulum could swing the other way entirely? keep everything as it used to be and lift the restrictions on functions requiring an exact amount of parameters??

the way it is now makes the most sense to me. if the asterisk is that much of a hindrance u could always make a macro for it

[lexikos]

=> expr. this seems like its introducing just another special case. whats the equivalent if the handler was a normal function? there isnt any, ud have to write *.

If => e is shorthand for (*) => e, the shorthand for a full function definition would be => e, and the equivalent would be a normal explicit definition. The entire purpose of => is brevity.

(*) is a significantly larger percentage of the overall function in (*) => expression than in

Code: Select all

function(*) {
    return expression
}

(*) => looks pretty weird in the middle of an expression, whereas (arg, *) => at least looks somewhat like a parameter list.

[iPhilip]

That was not the case in the previous version.

Of course it wasn't. That is why it was written in the change log (in the announcement post), which nnnik quoted. It is very important to read the change log before downloading a new alpha release. Every new release of any kind always includes something that was not the case in the previous version, and v2 alpha releases are not intended to be backward-compatible.

I appreciate the fact that you document the changes in the change log. I did read it before downloading the new alpha release. What I did not appreciate is the implication of the statements

Changed function calls to throw if too many parameters are passed.
Added fn(a,*) as a means to permit but not store surplus parameters.

on the OnEvent method. Upon further reading of the documentation, I came across this statement in the Callback Parameters section:

The callback's first explicit parameter is always Object; i.e. the Gui or GuiControl object which raised the event.

Thus, now I see that the Callback must allow at least one parameter, thus requiring the (*) in the above example. My understanding is that the word explicit in the above statement means any parameter that is not a bound parameter. For reference, the code below shows an example of the use of a bound parameter:

Code: Select all

myGui := GuiCreate()
myGui.AddText("", "Press Alt+F4 or the X button in the title bar.")
myGui.OnEvent("Close", Func("RealFn").Bind("string"))
myGui.Show

RealFn(bound_param, object) {
    MsgBox "Bound parameter: " bound_param "`nGui Title: " object.Title
}

Too manyfew parameters passed to function.

No, you are confusing "passed to" with "defined by". The GUI itself passes parameters too many parameters to your function, which defines too few parameters. The exception is thrown when the function is called, at which point there's no way to make the distinction. There's just a function, and a list of parameters being passed.

Thank you. I see the error in my thinking.

At some point I will revise the error handling code to permit more informative error messages without bloating the code. For instance, "Function {name} requires between {min} and {max} parameters, but was called with {actual}."

I can see how that could be useful.

After encountering this in my own scripts, I considered allowing => expr as short-hand for (*) => expr. Often the parameters aren't needed because the values are already available in the enclosing scope. If the function should strictly require 0 parameters, it can be written as () => expr.

I prefer the explicit use of (*) => expr. As @Helgef pointed out,

... it helps avoid errors and shows intent.

[lexikos]

My understanding is that the word explicit in the above statement means any parameter that is not a bound parameter.

You could interpret it that way, but no, that's not what it is referring to. "Explicit" is in contrast to "hidden" a few paragraphs up.

If the callback is a method registered by name, its hidden this parameter seamlessly receives the event sink object (that is, the object to which the method belongs). This parameter is not shown in the parameter lists in this documentation.

and the next paragraph

Since Callback can be an object, it can be a BoundFunc object which inserts additional parameters at the beginning of the parameter list and then calls another function. This is a general technique not specific to OnEvent, so is generally ignored by the rest of this documentation.

[iPhilip]

@lexikos Thank you for the clarification. For reference, here is an example using an event sink object:

Code: Select all

myGui := GuiCreate(,, Events)  ; Events is the "event sink object"
myGui.AddText("", "Press Alt+F4 or the X button in the title bar.")
myGui.OnEvent("Close", "Event_Close")  ; Callback is a method registered by name: Event_Close
myGui.Show

class Events {
   Event_Close(thisGui) {
      MsgBox "Closing Gui: " thisGui.title "`nand exiting."
   }
}

[Maestr0]

wow, ok, so during troubleshooting my issue (as mentioned earlier in this thread, I got the "Too many parameters passed to function." error), I found that when executing the tray command as stated below, it would execute function of the tray item as it was at the time when I executed the tray item, NOT the tray item as it was when the script was run. Is that by design?

Code: Select all

OnExit("f_exit")
tray := A_TrayMenu ; For convenience.
tray.delete ; Delete the standard items.
tray.add("reload error", "Reload")
tray.add("reload no error", (*) => Reload())
tray.add("exit", "f_exit")
return

f_exit(ExitReason, ExitCode) {
	if ( ExitReason != "Reload" )
	{
		; code to execute when the script exits
		msgbox ExitReason
	} else {
		; we are reloading, so we don't need to clean up files the script has opened
		msgbox "Reloading"
	}
	ExitApp
}

to reproduce, save the code above in a script and run it with the latest AHK version (2.0-a103-56441b52 at this time).
When the script is running, change the (*) => Reload() line to something else, and then select the "reload no error" menu item.

[Helgef]

@Maestr0, I cannot observe anything like you describe. When you run a script, the file is loaded by the program and any changes to it after that doesn't affect the running process. You can even delete the file without affecting the running process.

Cheers.

[Maestr0]

@Maestr0, I cannot observe anything like you describe. When you run a script, the file is loaded by the program and any changes to it after that doesn't affect the running process. You can even delete the file without affecting the running process.

Cheers.

Hmmm, it seems you're correct. I really did try it several times and I could reproduce it time and again. Weird.