AutoHotkey Community

[tinku99]

http://www.gnu.org/software/emacs/elisp/html_node/Advising-Functions.html

function hooks like the ability to advise functions in emacs elisp would be a nice feature to have in ahk.

It would help with debugging as well as metaprogramming.

Edit: Thanks for Lexikos
DebugBIF

Edit: adviseUDF for ahkv1.48 thanks to Lexikos.

[majkinetor]

This is called Aspect Oriented Programming and its way beyond AHK.

You could change your programming style to do something similar (although much less sophisticated) , using dynamic function calls.

The other thing is that you talk about something from Lisp and that is completely different paradigm. Lisp supports that kind of extreme but in lets say pure Object languages its usually implemented via postprocessr (see for instance PostSharp or AspectJ). This way it could be done in AHK too, although preprocessor would be more appropriate in this case.

AOP is fantastic and interesting thing, but it kills the simplicity of the language like AHK and there are not that many people there that would use that feature. It requires very experienced programmers.
_________________

[tinku99]

AOP can be thought of as a debugging tool or as a user level tool. Advice should be reserved for the cases where you cannot get the function changed (user level)http://www.gnu.org/software/emacs/elisp/html_node/Advising-Functions.html (from Emacs Documentation)] or do not want to change the function in production code (debugging).

Also, AOP is essentially a new class of hooks. AHK is all about hooking: user interfaces to 3rd party applications, windows api hooks.
One implementation would be for functions to automatically check for
A_ThisFunction%advice% and run it first.

I tried to hook dynamic function calls to start, but i am doing something wrong, would you mind looking at the following:
Thanks.
at line 702 in (Lexikos' custom build) script_expression.cpp after

[Lexikos]

That particular piece of code is part of "infix processing", where the expression text is converted into tokens. deref_start->func should always be NULL at that point, as the function name is not yet known. It is filled in later, when the SYM_DYNAMIC (i.e. %func_name% preceding the parameter list) is processed.

This approach is not ideal, anyway. You would need to handle it where SYM_FUNC is processed in order to call both functions, or to not require the function be called dynamically. You would also need to loop to call both the advice function and original function, unless the advice function explicitly calls the original function. Additional work would be needed to support multiple advice functions. Lastly, it is not intuitive, hurts performance and does not allow the advice functions to have meaningful names.

I think majkinetor suggestion was to use dynamic function calls, not to modify them.

[Lexikos]

[tinku99]

Thanks Lexikos.
That works nicely for user defined functions.
However, its not advisable to advise user defined functions, but to change the function call in the style recommended by majkinetor.

Could your approach work for builtin functions?

It would be even nicer if it worked for commands or script lines in general, particularly for things like gosub and return.

As for even lowerlevel stuff.
What do you think of hooking the cpp function in ahk that is reponsible for listing recently executed lines in the ListLines gui?

[tinku99]

It works for builtins if you override the builtin first:

[Lexikos]

[tinku99]

[Lexikos]

[tinku99]

I tried hooking a funciton, and it fails:

[Lexikos]

You misunderstand how RegisterCallbackCStub works:

• params is a pointer to the first parameter for the callback, ordinarily a location on the stack. If the callback has no parameters, "params" is not used. This will not necessarily be at the same address each time you run the script.
  
• address is not a string, but a pointer near the callback. Essentially, it is RegisterCallback(...)+5. Callbacks are dynamically allocated, so also will not necessarily be at the same address each time you run the script.
  

You could create an RCCallbackFunc structure, fill in the func field, then pass ((char*)cb)+5, but I would instead write code based on the contents of RegisterCallbackCStub or OnMessage to call the script function directly. This gives you control over how values are assigned to the parameters. A script function can be resolved by calling g_script.FindFunc.

Rather than doing this from each command (e.g. MouseMove), it would be more effective to hook Line::ExecUntil or Line::Perform. I believe g_act[line->mActionType].Name will retrieve a pointer to the command name in most cases, where line is instead this in Line::Perform. Control flow statements are handled directly by Line::ExecUntil, so hooking Line::Perform would not work for them.

[tinku99]

// adapted from IPC.ahk by Majkinetor

[Lexikos]

As I mentioned, you can call the script function directly, with code based on the contents of OnMessage. You may call any function with any number of parameters, passing numeric or non-numeric values. Using OnMessage and SendMessage to call a script function from within AutoHotkey itself is rediculous.

Yesterday I was writing an example of __mcode and __mcodeptr to put in the LowLevel documentation (for the next release), and realised I'd accidentally created something relevant to this thread. I decided not to use the example, but thought I'd polish it up and post it here:

[majkinetor]

Great for logging and troubleshooting. Thx.
_________________