When the event is raised, the COM server calls your event sink. AutoHotkey attempts to call your function, but instead throws an exception because there are too few parameters. Note that it
throws an exception and does not
display an error message.
Currently when an AutoHotkey object is called via IDispatch (even via our own COM event sink), any thrown exception is converted to a failure HRESULT. If the caller provides a non-null pExcepInfo (such as if the caller is the JScript engine), it is populated with the properties of the thrown exception and the result is DISP_E_EXCEPTION. Otherwise, the result is E_FAIL.
The COM event sink code currently always returns S_OK, since I had no clue what would (or should) happen if it returned failure. However, returning E_FAIL doesn't seem to make any difference for IE.NavigateComplete2 (I don't have Excel).
It would probably be more useful to show an error message for any uncaught (by AutoHotkey) exception, even though:
- Returning a failure result might cause the caller to show an additional error message.
- It might result in an inaccurate message: "The current thread will exit".
For event handlers, I have doubts about whether it is ever helpful to require all parameters to be defined. For COM event handlers, we add a parameter for the original COM object wrapper, since some events don't pass the object, and if the object is passed, it can't easily be used for comparison since it gets a new wrapper object.
If the restriction results in a general rule that "event handlers always have
*", perhaps the drawbacks outweigh the benefits. It would be possible to permit surplus parameters for functions being called by COM or an "On" event, although it would make them inconsistent with script-based "event-raising" code.